Tom Lane wrote:
> On HPUX 10.20, flock doesn't seem to exist (hasn't got a man page nor
> any mention in /usr/include).
Correct. Still isn't there in later releases.
> lockf says
>
> All locks for a process are released upon
> the first close of the file, even if the process still has the file
> opened, and all locks held by a process are released when the process
> terminates.
>
> and
>
> When a file descriptor is closed, all locks on the file from the
> calling process are deleted, even if other file descriptors for that
> file (obtained through dup() or open(), for example) still exist.
>
> which seems to imply (but doesn't actually say) that HPUX keeps track of
> exactly which process took out the lock, even if the file is held open
> by multiple processes.
Having done some testing today, I now understand what the standards
are trying to say when they talk about locks being "inherited". Or at
least I think I understand: standards are tricky, locking is subtle,
and I'm prepared to be corrected if I'm wrong!
All of these lock functions succeed when the same process asks for a
lock that it already has. That is:
fcntl(fd, ...);
fcntl(fd, ...); /* success -- no error returned */
For flock() only, the lock is inherited by a child process along
with the file descriptor so the child can re-issue the flock()
call and that will pass, too:
flock(fd, ...);
pid = fork();
if (pid == 0)
flock(fd, ...); /* success -- no error returned */
For fcntl() and lockf() the locks are not inherited, and the
call in a child fails:
fcntl(fd, ...);
pid = fork();
if (pid == 0)
fcntl(fd, ...); /* will fail and return -1 */
In no case does just closing the file descriptor in the child lose
the parent's lock. I rationalise this as follows:
1. flock() is using a "last close" semantic, so closing the file
descriptor is documented not to lose the lock
2. lockf() and fcntl() use a "first close", but because the locks
are not inherited by the child process the child can't unlock
them
> This all doesn't look good for using file locks in the way I had in
> mind :-( ... but considering that all these man pages seem pretty vague,
> maybe some direct experimentation is called for.
I conjecture that Tom was looking for a facility to lock a file and
have it stay locked if the postmaster or any child process was still
running. flock() fits the bill, but it's not portable everywhere.
One additional warning: this stuff *is* potentially filesystem
dependent, per the source code I looked at, which would call
filesystem specific routines.
I tested with HP-UX 11.00 (VxFS), NetBSD (FFS) and Linux (ext3). I've
put the rough and ready test code up for FTP, if anyone wants to check
my working:
ftp://ftp.nemeton.com.au/pub/pgsql/
Limitations in the testing:
I only used whole file locking (no byte ranges) and didn't prove that
a lock taken by flock() is still held after a child calls close() as
it is documented to be.
Regards,
Giles
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
