Thread

1. Re: Improving backend startup interlock

   Giles Lean <giles@nemeton.com.au> — 2002-09-28T22:37:20Z

   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
   
   

2. Re: Improving backend startup interlock

   Tom Lane <tgl@sss.pgh.pa.us> — 2002-09-29T01:47:59Z

   Giles Lean <giles@nemeton.com.au> writes:
   > 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?
   
   How would we know?  We have never tried to use such a feature.
   
   For sure I would not trust it on an NFS filesystem.  (Although we
   disparage running an NFS-mounted database, people do it anyway.)
   
   			regards, tom lane