Skip site navigation (1) Skip section navigation (2)

flock patch breaks things here

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: flock patch breaks things here
Date: 1998-08-30 05:42:03
Message-ID: 13213.904455723@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: TomDate: 1998-08-30 05:51:42
Subject: Re: [HACKERS] flock patch breaks things here
Previous:From: Bruce MomjianDate: 1998-08-30 05:11:10
Subject: new pg_upgrade command

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group