On Tue, Jul 29, 2014 at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think it would be good to spend some energy figuring out what to do
>> about this.
>
> Well, we've been around on this multiple times before, but if we have
> any new ideas, sure ...
Well, I tried to compile a more comprehensive list of possible
techniques in that email than I've seen anyone post before.
> Still, it's not clear to me how we could put much faith in flock.
Yeah, after some more research, I think you're right. Apparently, as
recently as 2010, the Linux kernel transparently converted flock()
requests to fcntl()-style locks when running on NFS:
http://0pointer.de/blog/projects/locking.html
Maybe someday this will be reliable enough to use, but the odds of it
happening in the next decade don't look good.
>> Finally, how about named pipes? Linux says that trying to open a
>> named pipe for write when there are no readers will return ENXIO, and
>> attempting to write to an already-open pipe with no remaining readers
>> will cause SIGPIPE. So: create a permanent named pipe in the data
>> directory that all PostgreSQL processes keep open. When the
>> postmaster starts, it opens the pipe for read, then for write, then
>> closes it for read. It then tries to write to the pipe. If this
>> fails to result in SIGPIPE, then somebody else has got the thing open;
>> so the new postmaster should die at once. But if does get a SIGPIPE
>> then there are as of that moment no other readers.
>
> Hm. That particular protocol is broken: two postmasters doing it at the
> same time would both pass (because neither has it open for read at the
> instant where they try to write). But we could possibly frob the idea
> until it works. Bigger question is how portable is this behavior?
> I see named pipes (fifos) in SUS v2, which is our usual baseline
> assumption about what's portable across Unixen, so maybe it would work.
> But does NFS support named pipes?
Looks iffy, on a quick search. Sigh.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
