Re: [HACKERS] flock patch breaks things here

[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(at)cs(dot)unitn(dot)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(at)candle(dot)pha(dot)pa(dot)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)