Re: Proposal to add a QNX 6.5 port to PostgreSQL

From: "Baker, Keith [OCDUS Non-J&J]" <KBaker9(at)its(dot)jnj(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal to add a QNX 6.5 port to PostgreSQL
Date: 2014-08-20 19:10:06
Message-ID: 25171C9D43848A4A9FFF65373179D8025AC11383@ITSUSRAGMDGD05.jnj.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert and Tom,

Sorry for any confusion, I will try to clarify.

Here is progression of events as I recall them:
- My Initial QNX 6.5 port proposal lacked a robust replacement for the existing System V shared memory locking mechanism, a show stopper.
- Robert proposed a nice set of possible alternatives for locking (to enable an all POSIX shared memory solution for future platforms).
- Tom and Robert seemed to agree that a combination of file-based locking plus pipe-based locking should be a sufficiently robust on platforms without Sys V shared memory (e.g., QNX).
- I coded a proof-of-concept patch (fcntl + PIPE) which appeared to work on QNX (steps a through e).
- Robert countered with an 11 step algorithm (all in the postmaster)
- Tom suggested elimination of steps 5,6,7,8, and 11 (and swapping order 9 and 10)

I was just taking a step back to ask what gaps existed in the proof-of-concept patch (steps a through e).
Is there a scenario it fails to cover, prompting the seemingly more complex 11 step algorithm (which added writing data to the pipe and handling of SIGPIPE)?

I am willing to attempt coding of the set of changes for a QNX port (option for new locking and all POSIX shared memory, plus a few minor QNX-specific tweaks), provided you and Tom are satisfied that the show stoppers have been sufficiently addressed.

Please let me know if more discussion is required, or if it would be reasonable for me (or someone else of your choosing) to work on the coding effort (perhaps targeted for 9.5?)
If on the other hand it has been decided that a QNX port is not in the cards, I would like to know (I hope that is not the case given the progress made, but no point in wasting anyone's time).

Thanks again for your time, effort, patience, and coaching.

Keith Baker

> -----Original Message-----
> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> Sent: Wednesday, August 20, 2014 12:26 PM
> To: Baker, Keith [OCDUS Non-J&J]
> Cc: Tom Lane; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] Proposal to add a QNX 6.5 port to PostgreSQL
>
> On Mon, Aug 18, 2014 at 11:02 AM, Baker, Keith [OCDUS Non-J&J]
> <KBaker9(at)its(dot)jnj(dot)com> wrote:
> > My proof of concept code (steps a though e below) avoided any reading or
> writing to the pipe (and associated handling of SIGPIPE), it just relied on
> postmaster open of PIPE with ENXIO to indicate all is clear.
>
> I'm not following.
>
> > Robert, Assuming an algorithm choice is agreed upon in the near future,
> would you be the logical choice to implement the change?
> > I am happy to help, especially with any QNX-specific aspects, but don't
> want to step on anyone's toes.
>
> I'm unlikely to have time to work on this in the immediate future, but I may
> be able to help review.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL
> Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-08-20 19:18:10 Re: jsonb format is pessimal for toast compression
Previous Message Robert Haas 2014-08-20 18:34:00 Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]