Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CA+hUKGKrYbSZhrk4NGfoQGT_3LQS5pC5KNE1g0tvE_pPBZ7uew@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Andres Freund <andres@anarazel.de>)
Responses Re: Cleaning up historical portability baggage
Re: Cleaning up historical portability baggage
List pgsql-hackers
On Sun, Aug 14, 2022 at 10:36 AM Andres Freund <andres@anarazel.de> wrote:
> On 2022-08-14 10:03:19 +1200, Thomas Munro wrote:
> > I hadn't paid attention to our existing abstract Unix socket support
> > before and now I'm curious: do we have a confirmed sighting of that
> > working on Windows?
>
> I vaguely remember successfully trying it in the past. But I just tried it
> unsuccessfully in a VM and there's a bunch of other places saying it's not
> working...
> https://github.com/microsoft/WSL/issues/4240

I think we'd better remove our claim that it works then.  Patch attached.

We could also reject it, I guess, but it doesn't immediately seem
harmful so I'm on the fence.  On the Windows version that Cirrus is
running, we happily start up with:

2022-08-13 20:44:35.174 GMT [4760][postmaster] LOG:  listening on Unix
socket "@c:/cirrus/.s.PGSQL.61696"

... and then client processes apparently can't see it, which is
confusing but, I guess, defensible if we're only claiming it works on
Linux.  We don't go out of our way to avoid this feature on a per-OS
basis in general, though at least on a typical Unix system it fails
fast.  For example, my FreeBSD system here barfs:

2022-08-15 13:26:13.483 NZST [29956] LOG:  could not bind Unix address
"@/tmp/.s.PGSQL.5432": No such file or directory

... because the kernel just sees an empty string and can't locate the
parent directory.

Attachment

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: bogus assert in logicalmsg_desc
Next
From: Masahiko Sawada
Date:
Subject: Re: Improve description of XLOG_RUNNING_XACTS