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

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Igor Kovalenko" <Igor.Kovalenko@motorola.com>
Cc: <pgsql-patches@postgresql.org>
Sent: Sunday, November 25, 2001 12:08 PM
Subject: Re: [PATCHES] Support for QNX6, POSIX IPC and PTHREAD-style locking


> "Igor Kovalenko" <Igor.Kovalenko@motorola.com> writes:
> >> 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.
>
> > I have feeling we're talking different languages. Can someone explain me
how
> > does it need lot of review and testing if all changes are #ifdef-ed and
> > invisible to all currently supported platforms?
>
> It needs review and testing because we're not convinced that it's right.
> We're not interested in shipping a possibly-unreliable QNX6 port just to
> have a QNX6 port.

You're mixing issues related to QNX6 port per say and to Posix semaphores in
that statement. There is nothing more unreliable (even potentially) in QNX6
port than in some other platforms. Implementation of Posix semaphores could
be considered non-proven, but that's separate issue. I already sent separate
patch which deals only with QNX6 support (no Posix semaphores, no Pthread
locking). It works through sysV emulation and should not be considered any
less reliable than QNX4 port (emulation code was essentially inherited from
there). Apparently it is still awaiting approval to be distributed. Bruce
has copy though.

> Also, patches that introduce a bunch of #ifdefs into what had been
> non-system-specific code are disliked on general principles around this
> project: they make the code harder to read and less maintainable over
> the long run.  In that sense the patch is going in the wrong direction.
> There needs to be some work done on restructuring the existing code to
> preserve readability.

You can not avoid #ifdefs completely. At some point somewhere you're bound
to have them. Of course it is better to have them encapsulated on lower
level. I believe that's what I did, except for those in proc.c & spin.c but
I already explained why I did that. So I don't think the patch goes in wrong
direction, it just goes half-way due to [intentional] compromise.

It could be structured better, but only at the cost of making more changes.

> I do believe that it's a good idea to support Posix semaphores; that's
> been in the wind for awhile, and it's clear that QNX6 is not the only
> platform that would benefit.  We will take up this code, in some form,
> in 7.3.  But I don't think it's a wise idea to cram it into 7.2.
> 7.2 is already two months behind schedule, and I don't want to risk
> any more delays in this release cycle.
>
> > ... What I get for that is people refusing to
> > accept the patch without even reading it. That's really encouraging ...
>
> I *have* read it.  More than once.  I'm not saying you've done bad work.
> It's a great starting point, in fact.  But I don't want to apply it
> as-is, and I don't want to hold up 7.2 anymore in order to get QNX6
> support into 7.2.

Bruce said he'd accept patch without Posix semaphores. And I asked to vote
3-way (whole patch, qnx6-support-only or none). What you're saying appears
to be 'none' but you're not making it clear if that's 'no to whole patch',
'no to posix semaphores', 'no to qnx6-support-only patch' or 'no to
anything'.

My understanding at this point is, there should not be problem with applying
QNX6-support-only patch, as long as it works within existing framework and
does not introduce non-proven code anywhere. That's what new version of
patch is.

regards,
- igor