"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 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.
> How about inserting postmaster_is_alive() as below?
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?
If you want to do something useful about this, the correct hint is
buried in start_postmaster():
/*
* Since there might be quotes to handle here, it is easier simply to pass
* everything to a shell to process them.
*
* XXX it would be better to fork and exec so that we would know the child
* postmaster's PID directly; then test_postmaster_connection could use
* the PID without having to rely on reading it back from the pidfile.
*/
If we had the postmaster's PID a priori, we could detect postmaster
death directly instead of having to make assumptions about how long
is reasonable to wait for the pidfile to appear. The problem is that
we don't want to write a complete replacement for the shell's command
line parser and I/O redirection logic. It doesn't look like a small
project.
(But maybe we could bypass that by doing a fork() and then having
the child exec() the shell, telling it to exec postmaster in turn?)
And of course Windows as usual makes things twice as hard, since we
couldn't make such a change unless start_postmaster could return the
proper PID in that case too.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
