From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: abstract Unix-domain sockets |
Date: | 2020-11-24 15:27:36 |
Message-ID: | CAKFQuwaNCWp82gy8hJyakMXkGzMjWDUzjAXx1rExABMTh6UW+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 23, 2020 at 9:00 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> Or is it the case that we always attempt to bind the TCP/IP port,
> regardless of the presence of a socket file, in which case the failure for
> port binding does cover the socket situation as well?
>
This cannot always be the case since the listened-to IP address matters.
I think the socket file error message hint is appropriate. I'd consider it
a bug if that code is effectively unreachable (the fact that the hint
exists supports this conclusion). If we add "abstract unix sockets" where
we likewise prevent two servers from listening on the same channel, the
absence of such a check for the socket file is even more unexpected. At
minimum we should at least declare whether we will even try and whether
such a socket file check is best effort or simply generally reliable.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-11-24 15:28:29 | Re: Prevent printing "next step instructions" in initdb and pg_upgrade |
Previous Message | Matthias van de Meent | 2020-11-24 15:25:03 | Re: [patch] CLUSTER blocks scanned progress reporting |