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
Re: Cleaning up historical portability baggage |
Список | 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 по дате отправления: