Re: POSIX shared memory redux - Mailing list pgsql-hackers

From Tom Lane
Subject Re: POSIX shared memory redux
Date
Msg-id 2691.1302743383@sss.pgh.pa.us
Whole thread Raw
In response to Re: POSIX shared memory redux  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> In answer to your off-list question, one of the principle ways I've
> seen fcntl() locking fall over and die is when someone removes the
> lock file.  You might think that this could be avoided by picking
> something important like pg_control as the log file, but it turns out
> that doesn't really work:

> http://0pointer.de/blog/projects/locking.html

Hm, I wasn't aware of the fact that you lose an fcntl() lock if you
close a *different* file descriptor for the same file.  My goodness,
that's horrid :-(.  It basically means that any third-party code running
in a backend could accidentally defeat the locking, and most of the time
you'd never even know it had happened ... as opposed to what would
happen if you detached from shmem for instance.  You could run with such
code for years, and probably never know why sometimes the interlock
failed to work when you needed it to.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: POSIX shared memory redux
Next
From: "A.M."
Date:
Subject: Re: POSIX shared memory redux