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 the postmaster to
produce a new postmaster.pid file. We really need to know the PID of
the process we started in order to make any real improvement here.
I'm sorry, but I may be missing the point of discussion. Let me clarify my
point again.
1.To be honest, I wish a real solution that can eliminate the problem
completely, for example, by using SIGCHLD approach Tom-san proposed before,
or by using unnamed pipes I proposed last year. However, the real solution
seems complicated to back-port to past versions.
2.As you said, we need any real improvement, if not a perfect solution, that
can lower the possibility of the problem. Doing something which can somehow
mitigate the problem is better than doing nothing and leaving the problem.
3.How long is it reasonable to wait for the postmaster to produce a new
postmaster.pid file?
No duration is reasonable.
4.Then, what can we do to mitigate the problem in the past versions (8.3,
8.4, 9.0)?
My very simple fix works well in the cases where old postmaster.pid file
exists. But it does not make any improvement in the cases where old
postmaster.pid is not left (i.e., running pg_ctl after clean shutdown; a
basic case).
Am I missing anything? Does the fix result in degradation in some cases?
Otherwise, is Tom-san saying:
"We will be able to solve the remaining problems completely if we can get
the pid of postmaster started in pg_ctl. We thought that it was not easy to
get the pid during 9.1 development. However, we might be able to get it more
easily than we thought, such as by fork-execing and making the child process
exec shell to make the new shell exec postmaster. So let's pursue the real
solution here."
If so, I agree. But if we find the real solution difficult, I wish my
"non-perfect" but somewhat effective solution will be accepted.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
