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.
> 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.
> 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'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.
regards, tom lane