Re: Questions about pid file creation code

Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Tom Lane wrote:
>>> Just to distinguish postmasters from standalone backends in the error
>>> messages.  I think that's still useful.
> 
>> I'm not sure what you mean. It is used only in CreatePidFile function 
>> and I think that if directory is locked by some process, I don't see any 
>> useful reason to know if it is postmaster or standalone backend.
> 
> You don't?  Consider the decisions the user needs to take upon seeing
> the message --- should he kill that other process or not, and if so how?
> Knowing whether it's a postmaster seems pretty important to me.

If somebody want to kill some process he must know what he want to do. 
How many postgres user know what is different between postmaster and 
postgres in error message?

And other problem. If another application (e.g. pg_migrator) want to 
lock this directory to prevent data corruption. How shall it do that? 
How big sense have this message in this case?

I suggest to remove this behavior and modify message.

>> Yes there are. But it does not sense for me. If I want to open file and 
>> another process remove it, why I want to try created it again when 
>> another process going to do it?
> 
> That could be the track of another postmaster just now shutting down.
> There's no reason to fail to start in such a scenario.  The looping
> logic is necessary anyway (to guard against races involving two
> postmasters trying to start at the same time), so we might as well let
> it handle this case too.

Ok. I now understand (I hope) what this loop try to handle. However, If 
one server go down and another go up there is only really small time 
piece between first open attempt and second one. I guess in this case we 
can say stop to the startup postmaster. For me it is better then make 
one hundred loops depend on cpu speed and recheck it again.  I think 
that in this case postgres doubled role of startup scripts.

There is also another issue which can occur. If you have two node with 
access to one shared filesystem. One node is for backup and somebody run 
postgres on second node. In this case postgres remove file and create 
own and two postgres on one dbcluster is not good idea. Good cluster 
solution protect this situation, but it can happen if somebody run it 
manually.

>> I'm sorry, I meant why there is a pid cleanup which stays there after 
>> another postmaster crash. Many application only check OK there is some 
>> pid file -> exit. And rest is on start script or some other monitoring 
>> facility.
> 
> The start script does not typically have the intelligence to get this
> right, particularly not the is-shmem-still-in-use part.  If you check
> the archives you will find many of us on record telling people who think
> they should remove the pidfile in their start script that they're crazy.

It is true, but question is what way is better. Keep all logic in 
postmaster or improve pg_ctl to share more information and keep 
responsibility on start scripts or monitoring tool which has more 
information about system as complex.

>>> It's not actually trying to validate the syntax of the lock file, only
>>> to make certain it doesn't trigger any unexpected behavior in kill().
> 
>> I not sure if we talk about same place.
> 
> Yes, we are.  Read the kill(2) man page and note the special behaviors
> for pid = 0 or -1.  The test is just trying to be darn certain we don't
> invoke those behaviors.

No we don't :-). I mean code few lines up after atoi().
with regards Zdenek