Re: Proposal to add a QNX 6.5 port to PostgreSQL

On Fri, Jul 25, 2014 at 3:16 PM, Baker, Keith [OCDUS Non-J&J]
<KBaker9(at)its(dot)jnj(dot)com> wrote:
> I propose that a QNX 6.5 port be introduced to PostgreSQL.
>
> I am new to PostgreSQL development, so please bear with me.
>
>
>
> I have made good progress (with 1 outstanding issue, details below):
>
> · I created a QNX 6.5 port of PostgreSQL 9.3.4 which passes
> regression tests.
>
> · I merged my changes into 9.4beta2, and with a few minor changes,
> it passes regression tests.
>
> · QNX support states that QNX 6.5 SP1 binaries run on QNX 6.6
> without modification, which I confirmed with a few quick tests.
>
>
>
> Summary of changes required for PostgreSQL 9.3.4 on QNX 6.5:
>
> · Typical changes required for any new port (template, configure.in,
> dynloader, etc.)
>
> · QNX lacks System V shared memory: I created
> “src/backend/port/posix_shmem.c” which replaces System V calls (shmget,
> shmat, shmdt, …) with POSIX calls (shm_open, mmap, munmap, shm_unlink)
>
> · QNX lacks sigaction SA_RESTART: I modified “src/include/port.h” to
> define macros to retry system calls upon EINTR (open,read,write,…) when
> compiled on QNX
>
> · A few files required addition of #include <sys/select.h> on QNX
> (for fd_set).
>
>
>
> Additional changes required for PostgreSQL9.4beta2 on QNX 6.5:
>
> · “DSM” changes introduced in 9.4 (R. Haas) required that I make
> minor updates to my new “posix_shmem.c” code.
>
> · src\include\replication\logical.h: struct LogicalDecodingContext
> field “write” interferes with my “write” retry macro. Renaming field
> “write” to “do_write” solved this problem.
>
>
>
> Outstanding Issue #1:
>
> src/backend/commands/dbcommands.c :: createdb() complains when copying
> template1 to template0 (apparently a locale issue)
>
> “FATAL: 22023: new LC_CTYPE (C;collate:POSIX;ctype:POSIX) is incompatible
> with the LC_CTYPE of the template database (POSIX;messages:C)”
>
> I would appreciate help from an experienced PostgreSQL hacker to address
> this.
>
> I have temporarily disabled this check on QNX (I can live with the
> assumption/limitation that template0 and template1 contain strictly ASCII).
>
> I can work toward setting up a build farm member should this proposal be
> accepted.

Maybe step #1 is to get a buildfarm member set up. Is there any
policy against unsupported environments in the buildfarm? (I hope not)

You're going to have to run it against a git repository containing
your custom patches. It's a long and uncertain road to getting a new
port (re-) accepted, but demonstrated commitment to support is a
necessary first step. It will also advertise support for the platform.

merlin