Thread
-
flock patch breaks things here
Tom Lane <tgl@sss.pgh.pa.us> — 1998-08-30T05:42:03Z
backend/libpq/pgcomm.c no longer compiles on my system. The cvs log sez Massimo Dal Zotto <dz@cs.unitn.it> > socket-flock.patch > use advisory locks to check if the unix socket can be deleted. > A running postmaster keeps a lock on that file. A starting > postmaster exits if the file exists and is locked, otherwise > it deletes the sockets and proceeds. > This avoid the need to remove manually the file after a postmaster > or system crash. > I don't know if flock is available on any system. If not we could > define a HAVE_FLOCK set by configure. flock is *VERY* far from portable. I am aware of three or four different, mutually incompatible file locking syscalls on different Unix flavors. flock is just one of the contestants. Even if the call syntax were uniform, the semantics are not portable enough to be safe (advisory locks don't work on NFS-mounted files, for example). Massimo has a good idea in the long run, but I have strong doubts that we want to start working the bugs out two days before a beta release cycle. Portable file locking in Unix is a very nasty can of worms, and I recommend not opening it at this particular point. In short: I'd like to see this patch backed out until after 6.4. regards, tom lane
-
Re: [HACKERS] flock patch breaks things here
Tom Samplonius <tom@sdf.com> — 1998-08-30T05:51:42Z
On Sun, 30 Aug 1998, Tom Lane wrote: > Massimo Dal Zotto <dz@cs.unitn.it> > > socket-flock.patch > > use advisory locks to check if the unix socket can be deleted. > > A running postmaster keeps a lock on that file. A starting > > postmaster exits if the file exists and is locked, otherwise > > it deletes the sockets and proceeds. > > This avoid the need to remove manually the file after a postmaster > > or system crash. > > I don't know if flock is available on any system. If not we could > > define a HAVE_FLOCK set by configure. > > flock is *VERY* far from portable. I am aware of three or four > different, mutually incompatible file locking syscalls on different > Unix flavors. flock is just one of the contestants. Even if the > call syntax were uniform, the semantics are not portable enough to > be safe (advisory locks don't work on NFS-mounted files, for example). You can't create unix domain sockets on NFS files systems (well, you might be allowed to, it just might not be very useful). The flock() call syntax is very consistant. The only other option is fcntl() which is very consistant too, and is described in POSIX.1 The only other option is lockf(). No one uses this anymore. It was only ever supported on SVR2,3,4 anyhow. It also is just a subset of fcntl() > Massimo has a good idea in the long run, but I have strong doubts that > we want to start working the bugs out two days before a beta release > cycle. Portable file locking in Unix is a very nasty can of worms, > and I recommend not opening it at this particular point. Not really. The biggest problem is NFS issues, which don't need to be considered for unix domain sockets. The various sematics issues don't really apply for locking is being used for. > In short: I'd like to see this patch backed out until after 6.4. > > regards, tom lane Tom
-
Re: [HACKERS] flock patch breaks things here
Massimo Dal Zotto <dz@cs.unitn.it> — 1998-08-30T11:04:43Z
> > backend/libpq/pgcomm.c no longer compiles on my system. The cvs log sez > > Massimo Dal Zotto <dz@cs.unitn.it> > > socket-flock.patch > > use advisory locks to check if the unix socket can be deleted. > > A running postmaster keeps a lock on that file. A starting > > postmaster exits if the file exists and is locked, otherwise > > it deletes the sockets and proceeds. > > This avoid the need to remove manually the file after a postmaster > > or system crash. > > I don't know if flock is available on any system. If not we could > > define a HAVE_FLOCK set by configure. > > flock is *VERY* far from portable. I am aware of three or four > different, mutually incompatible file locking syscalls on different > Unix flavors. flock is just one of the contestants. Even if the > call syntax were uniform, the semantics are not portable enough to > be safe (advisory locks don't work on NFS-mounted files, for example). > > Massimo has a good idea in the long run, but I have strong doubts that > we want to start working the bugs out two days before a beta release > cycle. Portable file locking in Unix is a very nasty can of worms, > and I recommend not opening it at this particular point. > > In short: I'd like to see this patch backed out until after 6.4. > Yes, I'm aware of this. For the moment I suggest we put a #ifdef linux around the code until a more portable solution is found. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-461-534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
-
Re: [HACKERS] flock patch breaks things here
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-08-30T12:19:52Z
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > > > backend/libpq/pgcomm.c no longer compiles on my system. The cvs log sez > > > > Massimo Dal Zotto <dz@cs.unitn.it> > > > socket-flock.patch > > > use advisory locks to check if the unix socket can be deleted. > > > A running postmaster keeps a lock on that file. A starting > > > postmaster exits if the file exists and is locked, otherwise > > > it deletes the sockets and proceeds. > > > This avoid the need to remove manually the file after a postmaster > > > or system crash. > > > I don't know if flock is available on any system. If not we could > > > define a HAVE_FLOCK set by configure. > > > > flock is *VERY* far from portable. I am aware of three or four > > different, mutually incompatible file locking syscalls on different > > Unix flavors. flock is just one of the contestants. Even if the > > call syntax were uniform, the semantics are not portable enough to > > be safe (advisory locks don't work on NFS-mounted files, for example). > > > > Massimo has a good idea in the long run, but I have strong doubts that > > we want to start working the bugs out two days before a beta release > > cycle. Portable file locking in Unix is a very nasty can of worms, > > and I recommend not opening it at this particular point. > > > > In short: I'd like to see this patch backed out until after 6.4. > > > > Yes, I'm aware of this. For the moment I suggest we put a #ifdef linux > around the code until a more portable solution is found. Can't we just have configure check for flock(). Another idea is to create a 'pid' file in the pgsql/data/base directory, and do a kill -0 to see if it is stil running before removing the lock. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)