| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christoph Berg <myon(at)debian(dot)org> |
| Cc: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)postgresql(dot)org, Adam Brusselback <adambrusselback(at)gmail(dot)com> |
| Subject: | Re: Postgres 10.1 fails to start: server did not start in time |
| Date: | 2017-11-12 19:26:42 |
| Message-ID: | 21519.1510514802@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Christoph Berg <myon(at)debian(dot)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. 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 ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | rob stone | 2017-11-12 19:52:49 | Re: pg on Debian servers |
| Previous Message | Christoph Berg | 2017-11-12 19:18:44 | Re: Postgres 10.1 fails to start: server did not start in time |