Re: Proposal to add a QNX 6.5 port to PostgreSQL - Mailing list pgsql-hackers

From Baker, Keith [OCDUS Non-J&J]
Subject Re: Proposal to add a QNX 6.5 port to PostgreSQL
Date
Msg-id 25171C9D43848A4A9FFF65373179D8025AC103CE@ITSUSRAGMDGD05.jnj.com
Whole thread Raw
In response to Re: Proposal to add a QNX 6.5 port to PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal to add a QNX 6.5 port to PostgreSQL
List pgsql-hackers
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@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

Attachment

pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: 9.5: Memory-bounded HashAgg
Next
From: Bruce Momjian
Date:
Subject: Re: jsonb format is pessimal for toast compression