On 2017-11-12 14:26:42 -0500, Tom Lane wrote:
> Christoph Berg <myon@debian.org> writes:
> > The default systemd timeout seems to be 90s. I have already changed
> > the systemd timeout to infinity (start) and 1h (stop), so only the
> > default pg_ctl timeout remains (60s), which I'd rather not override
> > unilaterally.
>
> > That said, isn't 60s way too small for shutting down larger clusters?
> > And likewise for starting?
>
> Well, that's tied into the fact that pg_ctl doesn't disturb the server's
> state if it gives up waiting. If it did, we would certainly use a larger
> timeout or none at all.
Hm. So partially that's also related to the fact that we didn't have a
good way to know whether the server reacted to the shutdown request or
not. With the infrastructure from
commit f13ea95f9e473a43ee4e1baeb94daaf83535d37c
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: 2017-06-28 17:31:24 -0400
Change pg_ctl to detect server-ready by watching status in postmaster.pid.
we could really do better than just wonder whether our signal to
shutdown was received or not. There probably should be a quite short
timeout for the server to change status, and then a much longer one for
that shutdown to finish.
> I don't feel a big need to change that default,
> but if you have a surrounding script that is going to take adverse action
> after a timeout then you need to use a larger value ...
Didn't we have to fiddle with this a bunch in the regression tests, to
get things to work properly on slow animals? If we had to do that, other
people had to do so as well. Not the friendliest experience...
Greetings,
Andres Freund
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
