Re: strange error reporting

On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> I find these new error messages to be more distracting than before in
> some cases. For example:
>
> PG13:
>
> clusterdb: error: could not connect to database typo: FATAL: database
> "typo" does not exist
>
> PG14:
>
> clusterdb: error: connection to server on socket "/tmp/.s.PGSQL.65432"
> failed: FATAL: database "typo" does not exist
>
> Throwing the socket address in there seems a bit distracting and
> misleading, and it also pushes off the actual information very far to
> the end. (Also, in some cases the socket path is very long, making the
> actual information even harder to find.) By the time you get to this
> error, you have already connected, so mentioning the server address
> seems secondary at best.

It feels a little counterintuitive to me too but I am nevertheless
inclined to believe that it's an improvement. When multi-host
connection strings are used, the server address may not be clear. In
fact, even when they're not, it may not be clear to a new user that
socket communication is used, and it may not be clear where the socket
is located. New users may not even realize that there's a socket
involved; I certainly didn't know that for quite a while. It's a lot
harder for the database name to be unclear, because since a particular
connection attempt will never try more than one, and also because when
it's relevant to understanding why the connection failed, the server
will hopefully include it in the message string anyway, as here. So
the PG13 message is really kind of silly: it tells us the same thing
twice, which we must already know, instead of telling us something
that we might not know.

It might be more intuitive in some ways if the socket information were
demoted to the end of the message, but I think we'd lose more than we
gained. The standard way of reporting someone else's error is
basically "what i have to say about the problem: %s" and that's
exactly what we're doing here. We could find some way of gluing the
information about the socket onto the end of the server message, but
it seems unclear how to do that in a way that looks natural, and it
would depart from our usual practice. So even though I also find this
to be a bit distracting, I think we should just live with it, because
everything else seems worse.

--
Robert Haas
EDB: http://www.enterprisedb.com