> "Marc G. Fournier" <scrappy@hub.org> writes:
> > Since our default behavior (at startup) is to have TCP sockets disabled,
> > how many OSs are there that don't support UD sockets?
>
> A quick look in the sources shows that we #undef HAVE_UNIX_SOCKETS for
> QNX, BeOS, and old cygwin versions ... which are exactly the platforms
> that don't have SysV shmem support, so those are exactly the guys who
> we're trying to fix the problem for.
Next release of QNX (6.2) will add support for UDS, but they are still not
quite portable.
>
> I do like the idea of using a Unix socket this way where available,
> though. It'd let us switch over the shmem code to using IPC_PRIVATE
> shmem key, which'd simplify that code tremendously; and we could make
> some progress against the dead-PID-in-lockfile problem.
>
> Could we get away with saying that the Unix-socket-less platforms have
> weaker protection against mistakenly restarting the postmaster? We
> could have a plain-vanilla lockfile instead of a socket lockfile on
> those platforms, which would not catch the dead-postmaster-live-backends
> case, but it'd be better than nothing. And I am not convinced that the
> shmem-connection-count check should be trusted on QNX or BeOS, anyway,
> so I'm not sure that they actually have a functioning check now.
Why can't we use named pipe (aka FIFO file) instead of UDS? I think that is
more portable... The socketpair() function also tends to be more portable
than whole UDS in general... It works on QNX4 even, but not sure about BeOS.
Another thought is, why can't we use bind() to the postmaster port to detect
other postmasters? I might be missing something, so pardon by ignorance. But
should not bind() to same port fail with EADDRINUSE unless SO_REUSEADDR is
set? I don't really know if it is set in postgres or not ...
-- igor
