Re: HEADS UP: Win32/OS2/BeOS native ports

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org>, Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>, mlw <markw(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Date: 2002-05-06 15:19:54
Message-ID: 5598.1020698394@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)hub(dot)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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nigel J. Andrews 2002-05-06 15:31:05 Re: Schemas: status report, call for developers
Previous Message Marc G. Fournier 2002-05-06 14:55:48 Re: HEADS UP: Win32/OS2/BeOS native ports