Robert and Tom,
Please let me know if either of you are ready to experiment with the "named pipe" idea anytime soon.
If not, I would be happy to take a crack at it, but would appreciate your expert advice to start me down the right path
(files/functionsto update, pseudo-code, etc.).
-Keith Baker
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Wednesday, July 30, 2014 11:02 AM
> To: Robert Haas
> Cc: Baker, Keith [OCDUS Non-J&J]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Proposal to add a QNX 6.5 port to PostgreSQL
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Tue, Jul 29, 2014 at 7:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
>
> I poked around, and it seems like a lot of the people who think it's flaky are
> imagining that they should be able to use a named pipe on an NFS server to
> pass data between two different machines. That doesn't work, but it's not
> what we need, either. For communication between processes on the same
> server, all that's needed is that the filesystem entry looks like a pipe to the
> local kernel --- and that's been required NFS functionality since RFC1813 (v3,
> in 1995).
>
> So it seems like we could possibly go this route, assuming we can think of a
> variant of your proposal that's race-condition-free. A disadvantage
> compared to a true file lock is that it would not protect against people trying
> to start postmasters from two different NFS client machines --- but we don't
> have protection against that now. (Maybe we could do this *and* do a
> regular file lock to offer some protection against that case, even if it's not
> bulletproof?)
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
