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

My reply went only to Peter. Can't get used to the fact that this list sends
replies to author rather than list ;)

----- Original Message -----
From: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
To: "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>; <pgsql-patches(at)postgresql(dot)org>
Sent: Monday, November 26, 2001 1:15 PM
Subject: Re: [PATCHES] Support for QNX6, POSIX IPC and PTHREAD-style locking

> Igor Kovalenko writes:
>
> > Fair enough. I am asking you to get something into 7.2 for practical
> > reasons. Sooner people will get something, sooner someone will uncover
> > problems is there are any. That would allow to have reasonable
confidence by
> > the time 7.3 rolled out.
>
> The patch looks mostly harmless in the sense that it doesn't break
> anything else, although some parts are clearly bogus,

I am all for making it 'proper' if you elaborate a bit.

> such as the patches
> to 'configure' and 'resultmap'

How those are bogus? Configure needs to recognize system, otherwise it will
say Postgres has not been ported to your OS ....

Patch to resultmap is not as bogus as it may seem to you. Trouble is, the
QNX4 port plays against QNX6 there, by 'fake' matches which are not
appropriate for QNX6. That happens because host ID string (as produced by
config.guess) contains common part on both systems. Since I did not want to
touch other ports, I had little choice but to force matching with proper
files on QNX6, even if they are default files (otherwise QNX4-specific ones
were matched, producing bogus 'failures' of tests). You don't think I would
put things in there for no reason, would you?

> and some "comment out if you want xyz"
> comments where there's nothing to comment out nearby. (Plus, commenting
> stuff in and out in makefiles is not an acceptable practice to spread.)

Those comments are leftover from Posix semaphores stuff. Those makefiles
would not need to be patched if Posix semaphores were used, but patches are
needed otherwise. If you can tell me how to handle that more elegantly, I am
all ears. Since now there's no posix semaphores in the patch, those comments
can be wiped out, I just did not think it would be such a bad sin to have
them there. Assuming there will be Posix semaphores eventually, some
comments would need to be there again...

> CFLAGS in template/qnx6 should probably be -O2 unless you have reasons to
> do otherwise, which should be documented.

It is somewhat problematic on QNX. Takes a lot of memory to compile and is
prone to 'internal compiler errors'. The default is -O anyway.

> LIBS= has no business in the
> template file.

I did not invent it. Template was copied from QNX4, how I was supposed to
know what has business there and what not. Univel and Windows have LIBS in
template too.

> Overriding CC as done in port/qnx6/Makefile is not valid.

This one is my bad...

> The SHLIB_LINK line in Makefile.shlib is not possibly correct. (The same
> goes for most of the other SHLIB_LINK lines there, btw.) These issues are

SHLIB_LINK was copied from other platforms, most of which have -lc there.
Following the logic in comments, I added -lm -lsocket since they are
certainly needed on QNX6. If that's not possibly correct, you should educate
us all.

> "mostly harmless", but they would need to be fixed.
>
> My mind on this is that we hope to put out the first *release candidate*
> this week, which means, "if there are no more serious bugs, this is the
> final release". This would mean that this patch would receive virtually
> *no* testing before release. Surely I trust your word that says that this
> patch makes PostgreSQL run correctly on your system, and it doesn't look
> like it'll break anything else. But this kind of reasoning is not
> responsible. PostgreSQL is, for better or worse, not developed by proving
> that the code is theoretically correct; we allocate for extensive beta
> testing because we know we need extensive beta testing.

The patch was being tested for last couple of weeks by several people. The
fact that is passes regression tests should give some confidence too,
otherwise what is the point to have them at all.

> Exceptions are
> always made, but a new feature has never qualified for such an exception.
>
> "There will always be another release."

Sure. I think I made it clear enough why I want it in 7.2. I also took away
the most interesting part of patch since there were some valid logical
objections against including it as is. I thought that would clear the way,
but now I am presented with unbeatable 'this is untested' reason. Who do you
think would be testing it if it was included in 7.3 or 8.0 for that matter?
Not you, I suspect. That would be same old me probably and why do you think
few weeks of testing by me and my fellows then will be somehow better than
same testing we've done now?

regards,
- igor