Re: HEADS UP: Win32/OS2/BeOS native ports - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: HEADS UP: Win32/OS2/BeOS native ports
Date
Msg-id 20020506115503.B32524-100000@mail1.hub.org
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets?  Enough to really be
worried about?




On Mon, 6 May 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> >> That would work ... but is it more portable than depending on SysV
> >> shmem connection counts?  ISTR that some of the platforms we support
> >> don't have Unix-style sockets at all.
>
> > Wouldn't the same thing work with a simple file?  Does it have to be a
> > UnixDomainSocket?
>
> No, and yes.  If it's not a pipe/fifo then you don't get the
> EOF-only-when-no-possible-writers-remain behavior.  TCP and UDP
> sockets don't show this sort of behavior either.  So AFAICS we
> really need a named pipe, ie, socket.
>
> We could maybe do something approximately similar with TCP connection
> attempts (per the prior suggestion of letting backends hold the
> postmaster's listen socket open; then see if you get "connection
> refused" or a timeout from trying to connect) but I don't think it'd be
> as trustworthy.  Simple mistakes like overly aggressive ipchains filters
> would confuse this kind of test.
>
>             regards, tom lane
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Next
From: Tom Lane
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports