Re: Proposal to add a QNX 6.5 port to PostgreSQL

Tom and Robert,

I tried a combination of PIPE lock and file lock (fcntl) as Tom had suggested.
Attached experimental patch has this logic...

Postmaster :
- get exclusive fcntl lock (to guard against race condition in PIPE-based lock)
- check PIPE for any existing readers
- open PIPE for read

All other backends:
- get shared fcnlt lock
- open PIPE for read

Your feedback is appreciated.
Thanks.

-Keith Baker

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)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(at)postgresql(dot)org
> Subject: Re: [HACKERS] Proposal to add a QNX 6.5 port to PostgreSQL
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Jul 29, 2014 at 7:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org) To make
> changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers