Hello,
Last year, I asked for your opinions about how to fix the bug of unreliable
pg_ctl -w start, as in the thread:
http://archives.postgresql.org/pgsql-hackers/2011-05/msg01407.php
The phenomenon was that pg_ctl -w start did not return for 60 seconds when
postgresql.conf contained a
MauMau maumau...@gmail.com writes:
In PostgreSQL 9.1, the wait processing is largely modified. However, the
same assumption seems to still remain, though the duration is 5 seconds. 5
seconds of wait is probably insufficient for my case. I think no fixed
duration is appropriate.
Well, feel
From: Tom Lane t...@sss.pgh.pa.us
Well, feel free to increase that duration if you want. The reason it's
there is to not wait for a long time if the postmaster falls over
instantly at startup, but in a non-interactive situation you might not
care.
Yes, just lengthening the wait duration
From: Tom Lane t...@sss.pgh.pa.us
Well, feel free to increase that duration if you want. The reason it's
there is to not wait for a long time if the postmaster falls over
instantly at startup, but in a non-interactive situation you might not
care.
Yes, just lengthening the wait duration
MauMau maumau...@gmail.com writes:
From: Tom Lane t...@sss.pgh.pa.us
Looks like complete nonsense to me, if the goal is to behave sanely when
postmaster.pid hasn't been created yet. Where do you think get_pgpid
gets the PID from?
Yes, I understand that get_pgpid() gets the pid from
From: Tom Lane t...@sss.pgh.pa.us
I don't see any point in worrying about that case when you can't handle
the basic case that the postmaster hasn't created postmaster.pid yet.
In any case, this does nothing at all to answer the question you posed,
which was how long is it reasonable to wait for