Re: abstract Unix-domain sockets

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.

In response to

Browse pgsql-hackers by date

  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