Re: Support for QNX6, POSIX IPC and PTHREAD-style locking - Mailing list pgsql-patches

From Tom Lane
Subject Re: Support for QNX6, POSIX IPC and PTHREAD-style locking
Date
Msg-id 16060.1006624030@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support for QNX6, POSIX IPC and PTHREAD-style locking  ("Igor Kovalenko" <Igor.Kovalenko@motorola.com>)
Responses Re: Support for QNX6, POSIX IPC and PTHREAD-style locking  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
"Igor Kovalenko" <Igor.Kovalenko@motorola.com> writes:
> We had some more discussion with Bruce on the nature of changes.
> Essentially, my point is that all the changes will only be seen on QNX6,
> with or without Posix semaphore stuff, unless other platforms will
> explicitly enable new code.

No, the point is that the Posix semaphore stuff is a major change to a
critical and delicate part of Postgres.  It's too late in the 7.2 beta
cycle for such a change to receive the review and testing it needs.
We'll gladly consider it as a non-QNX-specific improvement for 7.3.
We won't ship it in 7.2, QNX-only or otherwise, because we don't have
any confidence in it yet (and no, we don't want to delay 7.2 release
for it either).

While I agree that a SysV emulation layer is ugly, it's by now a
well-tested technology: we've got several other platforms that do it
that way and have been known to work for a few releases.  I have some
confidence that that same approach can be transposed into QNX6 and be
trustworthy enough to release with limited testing.  I don't yet have
any confidence in changes at higher levels.

Also, I think that your patch as it stands is really only a halfway
measure; it makes the code uglier rather than cleaner.  We probably
ought to revamp the higher-level APIs in such a way that either Posix
or SysV semaphores can be used to implement the APIs reasonably cleanly.
I'd prefer to design those changes and revise semaphore handling once,
not tweak it a little in this release and some more in the next.

Perhaps what this really means is that it's too late to think of
supporting QNX6 in PG 7.2 at all, and that we should target it for 7.3
instead.  Considering that we're hoping to put out a final candidate
tarball next week, this train has pretty much left the station already.

            regards, tom lane

pgsql-patches by date:

Previous
From: Weiping He
Date:
Subject: Re: Chinese NLS patch, the third try.
Next
From: Brent Verner
Date:
Subject: fixes for date_part micro/millisecond precision