Re: Unreliable "pg_ctl -w start" again - Mailing list pgsql-hackers

From MauMau
Subject Re: Unreliable "pg_ctl -w start" again
Date
Msg-id 1B2CBF77B74043E9B8DDAD04E333E7C3@maumau
Whole thread Raw
In response to Re: Unreliable "pg_ctl -w start" again  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
From: "Tom Lane" <tgl@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




pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: initdb and fsync
Next
From: Magnus Hagander
Date:
Subject: Re: Temp file missing during large pgbench data set