Re: Support for QNX6, POSIX IPC and PTHREAD-style locking

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com>
Cc: <pgsql-patches(at)postgresql(dot)org>
Sent: Saturday, November 24, 2001 11:47 AM
Subject: Re: [PATCHES] Support for QNX6, POSIX IPC and PTHREAD-style locking

> "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)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.

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? I just want to understand
that point...

> 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.

Does that mean you'd be ok with patch if it did not have Posix semaphores
and worked through sysV emulation? I could easily take that part out.

We already had similar discussion with Bruce and he was also objecting in
similar way until I explained the patch piece by piece and demonstrated why
I think it is harmless. Consider following pseudocode:

#ifdef HAVE_POSIX_IPC
// new code
#else
// unmodified old code
#endif

How does that shatter your confidence? Please educate me.

> 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.

Theoretically, yes and so far this is the only valid argument that I see.
Indeed it would be better to revamp IpcSemaphoreXXX() API to cover SysV,
Posix and BeOS semaphores. I wanted to do that, but I did not because I
anticipated concerns about changing existing code. So my goal was to change
as little of it as possible. I hoped it would help me to get it into 7.2,
but now you're pointing to it as to a mistake ;)

In practice you have to start with something and it is not always bad idea
to start with smaller steps. You may keep thinking about higher goals for a
year and nothing will happen until someone willing to spend his time on that
comes in and does it. I already spent mine and even went out of my way to
test it on various platforms. What I get for that is people refusing to
accept the patch without even reading it. That's really encouraging ...

> 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.

I think I asked for formal vote. Delaying it for 7.3 means somebody will
have to essentially redo it and I did not see any volunteers popping up yet.

regards,
- igor