Re: [GENERAL] Postgres 10.1 fails to start: server did not start intime
| От | Christoph Berg | 
|---|---|
| Тема | Re: [GENERAL] Postgres 10.1 fails to start: server did not start intime | 
| Дата | |
| Msg-id | 20171112191844.4rry32vdtxzi6crj@msg.df7cb.de обсуждение исходный текст  | 
		
| Ответ на | Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time
            		
            		 | 
		
| Список | pgsql-general | 
Re: Tom Lane 2017-11-12 <20802.1510513605@sss.pgh.pa.us> > Agreed, but I think Peter has a point: why is there a timeout at all, > let alone one as short as 30 seconds? Since systemd doesn't serialize > service starts unnecessarily, there seems little value in giving up > quickly. And we know that cases such as crash recovery may take more > than that. 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. https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/tree/systemd/postgresql@.service#n18 That said, isn't 60s way too small for shutting down larger clusters? And likewise for starting? Christoph -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: