Re: pg_ctl configurable timeout
От | Tom Lane |
---|---|
Тема | Re: pg_ctl configurable timeout |
Дата | |
Msg-id | 25778.1193689459@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_ctl configurable timeout (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: