Re: Cleaning up historical portability baggage

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Cleaning up historical portability baggage
Дата
Msg-id CA+hUKGKrYbSZhrk4NGfoQGT_3LQS5pC5KNE1g0tvE_pPBZ7uew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cleaning up historical portability baggage  (Andres Freund <andres@anarazel.de>)
Ответы Re: Cleaning up historical portability baggage  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Re: Cleaning up historical portability baggage  (Andres Freund <andres@anarazel.de>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: bogus assert in logicalmsg_desc
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Improve description of XLOG_RUNNING_XACTS