Re: [HACKERS] Improving backend startup interlock

2002-10-04 Thread Joe Conway
Michael Paesold wrote: > Giles Lean <[EMAIL PROTECTED]> wrote: >>Mind you NFS users are currently entirely unprotected from someone >>starting a postmaster on a different NFS client using the same data >>directory right now, which file locking would prevent. So there is >>some win for NFS users as

Re: [HACKERS] Improving backend startup interlock

2002-10-04 Thread Michael Paesold
Giles Lean <[EMAIL PROTECTED]> wrote: > Tom Lane writes: > > > $ man flock > > No manual entry for flock. > > $ > > > > HPUX has generally taken the position of adopting both BSD and SysV > > features, so if it doesn't exist here, it's not portable to older > > Unixen ... > > If only local loc

Re: [HACKERS] Improving backend startup interlock

2002-10-04 Thread Giles Lean
Tom Lane writes: > $ man flock > No manual entry for flock. > $ > > HPUX has generally taken the position of adopting both BSD and SysV > features, so if it doesn't exist here, it's not portable to older > Unixen ... If only local locking is at issue then finding any one of fcntl() locking, fl

Re: [HACKERS] Improving backend startup interlock

2002-10-03 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Have people considered flock (advisory locking) on the postmaster.pid > file for backend detection? $ man flock No manual entry for flock. $ HPUX has generally taken the position of adopting both BSD and SysV features, so if it doesn't exist here, it's

Re: [HACKERS] Improving backend startup interlock

2002-10-03 Thread Bruce Momjian
Have people considered flock (advisory locking) on the postmaster.pid file for backend detection? It has a nonblocking option. Don't most OS's support it? I can't understand why we can't get an easier solution to postmaster detection than shared memory. --

Re: [HACKERS] Improving backend startup interlock

2002-09-28 Thread Tom Lane
Giles Lean <[EMAIL PROTECTED]> writes: > I'm certainly no fan of NFS locking, but if someone trusts their NFS > client and server implementations enough to put their data on, they > might as well trust it to get a single lock file for startup right > too. IMHO. Your mileage may vary. Well, my l

Re: [HACKERS] Improving backend startup interlock

2002-09-28 Thread Giles Lean
Tom Lane wrote: > Giles Lean <[EMAIL PROTECTED]> 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

Re: [HACKERS] Improving backend startup interlock

2002-09-28 Thread Tom Lane
Giles Lean <[EMAIL PROTECTED]> 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

Re: [HACKERS] Improving backend startup interlock

2002-09-28 Thread Giles Lean
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 exclusiv

[HACKERS] Improving backend startup interlock

2002-09-28 Thread Tom Lane
I have the beginnings of an idea about improving our interlock logic for postmaster startup. The existing method is pretty good, but we have had multiple reports that it can fail during system boot if the old postmaster wasn't given a chance to shut down cleanly: there's a fair-sized chance that