Re: Proposal to add a QNX 6.5 port to PostgreSQL

Hi,

On 2014-08-21 15:25:44 +0000, Baker, Keith [OCDUS Non-J&J] wrote:
> About SA_RESTART:
> ------------------------
> I would like to offer you a different perspective which may alter your current opinion.
> I believe the port.h QNX macro replacement for SA_RESTART is still a reasonable solution on QNX for these reasons:
>
> First, I think it is better to adapt PostgreSQL to suit the platform
> than to adapt the platform to suit PostgreSQL.

Well. That might be somewhat true for a popular platform. Which QNX
really isn't. I personally don't believe your approach to be likely to
end up with a correct and maintainable port.

> Changing default behavior of libc on QNX to suit PostgreSQL may break
> other applications which rely on the current behavior of libc.

I don't see how *adding* SA_RESTART support which would only be used
when SA_RESTART is being passed to sigaction(), would do that.

> Yes, I could forget to add a port.h macro for a given interruptible
> primitive, but I could likewise forget to update the wrapper for that
> call in a custom libc.

> I requested that QNX support provide me a list of interruptible
> primitives, but I was able to identify many by searching through the
> QNX help. Definition of a new interruptible primitive is a rare
> event, so once a solid list of macros is in place for QNX, it should
> need very little maintenance. If you have any specific calls you
> believe are missing from my list of macros, I would be happy to add
> them.

I have no idea whether there are any other ones - I don't have access to
a QNX machine, and I don't personally wan't any. The problem is that we
might want to start using new syscalls or QNX might introduce new
interruptible signals. Problems caused by missed interruptible syscalls
won't show during low-load testing like pg_regress. They'll show up
during production usage.

> port.h is included in c.h, which is in postgres.h, so the QNX macros
> should be effective for all QNX PostgreSQL compiles. If it were not,
> no one could reply on any port.h features on any platform.

Yea, that's not a concern I have.

> The first release on any platform has risk of defects, which can be
> corrected once identified. I would expect that a first release on any
> platform would include a warning or disclaimer stating that it is new
> port.
>
> Lastly, the QNX-specific section added to port.h appears to solve the
> SA_RESTART issue for QNX, while having no impact on compiles of
> existing platforms.

My problem is that it's ugly hack for a niche paltform that will need to
be maintained for a long while into the future. I don't have a problem
adding support for not that frequently used platforms if the support is
very localized, but that's definitely not the case here.

> About configure:
> --------------------
> "./configure" barked at 2 things on QNX, and it advised using both
> "--without-readline --disable-thread-safety". I can investigate
> further, but I have been focusing on the bigger issues first.

Yea, those aren't really critical. It'd be interesting to know why the
the thread safety test fails - quite possibly it's just the configure
test for pthreads not being very good.

Greetings,

Andres Freund