Re: Improving backend startup interlock

Tom Lane wrote:

[ discussion of new startup interlock ]

> This is not quite ready for prime time yet, because it's not very
> bulletproof against the scenario where two would-be postmasters are
> starting concurrently.

A solution to this is to require would-be postmasters to obtain an
exclusive lock on a lock file before touching the pid file. (The lock
file perhaps could be the pid file, but it doesn't have to be.)

Is there some reason that file locking is not acceptable? Is there
any platform or filesystem supported for use with PostgreSQL which
doesn't have working exclusive file locking?

> A possible answer is to create a second lockfile that only exists
> for the duration of the startup sequence, and use that to ensure
> that only one process is trying this sequence at a time.
> ...
> This reintroduces the same problem
> we're trying to get away from (must rely on kill(PID, 0) to determine
> validity of the lock file), but at least the window of vulnerability is
> much smaller than before.

A lock file locked for the whole time the postmaster is running can be
responsible for preventing multiple postmasters running without
relying on pids. All that is needed is that the OS drop exclusive
file locks on process exit and that locks not survive across reboots.

The checks of the shared memory segment (number of attachements etc)
look after orphaned back end processes, per the proposal.

Regards,

Giles