Peter Eisentraut <peter_e@gmx.net> writes:
> Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we
> should remove it altogether. We could add an option as described above, but
> then the packager who creates the init script or whoever creates the initial
> configuration will have to make an equally arbitrary choice.
Yeah. One problem is that we use the same timeout for startup and
shutdown, which really are entirely different; and the other problem
is that we've not wanted pg_ctl to have too many smarts about the
server's internal behavior.
On startup, it would be reasonable to assume failure if we don't see
a postmaster pid-file appear PDQ, but then after that it might stay
in the "database is starting up" state for a long time (maybe even
indefinitely if it's a warm standby server). Still, you could argue
that it's reasonable to keep waiting as long as the postmaster keeps
returning "database is starting up" when pinged.
On shutdown, it'd be reasonable to expect that the postmaster starts
returning "database is shutting down" almost immediately, and to report
failure if not. However, if it was a default "smart mode" stop you
could again wait indefinitely for clients to decide to give up their
sessions. I'm not sure if it's sane for pg_ctl to wait indefinitely
in that scenario.
I agree that just pushing the choice of timeout onto the user's
shoulders wouldn't be much of an improvement. He can always hit ^C
if he gets tired of waiting.
regards, tom lane
