Re: Proposal to add a QNX 6.5 port to PostgreSQL
От | Tom Lane |
---|---|
Тема | Re: Proposal to add a QNX 6.5 port to PostgreSQL |
Дата | |
Msg-id | 9142.1406327393@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Proposal to add a QNX 6.5 port to PostgreSQL ("Baker, Keith [OCDUS Non-J&J]" <KBaker9@its.jnj.com>) |
Ответы |
Re: Proposal to add a QNX 6.5 port to PostgreSQL
Re: Proposal to add a QNX 6.5 port to PostgreSQL |
Список | pgsql-hackers |
"Baker, Keith [OCDUS Non-J&J]" <KBaker9@its.jnj.com> writes: > I propose that a QNX 6.5 port be introduced to PostgreSQL. Hmm ... you're aware that there used to be a QNX port? We removed it back in 2006 for lack of interest and maintainers, and AFAIR you're the first person to show any interest in reintroducing it since then. I'm a bit concerned about reintroducing something that seems to have so little usage, especially if the port is going to be as invasive as you suggest: > * 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) This isn't really acceptable for production usage; if it were, we'd have done it already. The POSIX APIs lack any way to tell how many processes are attached to a shmem segment, which is *necessary* functionality for us (it's a critical part of the interlock against starting multiple postmasters in one data directory). > * 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 That's pretty scary too. For one thing, such macros would affect every call site whether it's running with SA_RESTART or not. Do you really need it? It looks to me like we just turn off HAVE_POSIX_SIGNALS if you don't have SA_RESTART. Maybe that code has bit-rotted by now, but it did work at one time. regards, tom lane
В списке pgsql-hackers по дате отправления: