Horton

Thread

Commits

  1. Fix redundant error messages in client tools

  1. redundant error messages

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2020-11-05T12:27:21Z

    A few client tools duplicate error messages already provided by libpq, 
such as

pg_rewind: fatal: could not connect to server: could not connect to 
server: No such file or directory

pg_basebackup: error: could not connect to server: could not connect to 
server: No such file or directory

psql: error: could not connect to server: could not connect to server: 
No such file or directory

The psql case is actually a regression introduced in PG12, but the other 
two appear to be ancient.

Other client tools provide a different error message so in aggregate it 
looks like this:

createdb: error: could not connect to database template1: could not 
connect to server: No such file or directory

The attached patch removes the redundant message from the client tools. 
I suppose it's a bit dubious because there is no guarantee what the 
level of detail the message supplied by libpq has.  But I think these 
few cases are not particularly hard to keep in sync.

  2. Re: redundant error messages

    Euler Taveira <euler.taveira@2ndquadrant.com> — 2020-11-05T13:34:06Z

    On Thu, 5 Nov 2020 at 09:27, Peter Eisentraut <
peter.eisentraut@enterprisedb.com> wrote:

> A few client tools duplicate error messages already provided by libpq,
> such as
>
> pg_rewind: fatal: could not connect to server: could not connect to
> server: No such file or directory
>
> Good catch!


> Other client tools provide a different error message so in aggregate it
> looks like this:
>
> createdb: error: could not connect to database template1: could not
> connect to server: No such file or directory
>
> Is the database name important for this message? You should inform which
database you want to connect for all client tools except pg_dumpall. Hence,
you
already know which database has the connection problem. IMO the pg_dumpall
message should inform the database name. My suggestion is:

        if (fail_on_error)
        {
            pg_log_error("database \"%s\": %s",
                         dbname, PQerrorMessage(conn));
            exit_nicely(1);
        }

and remove the redundant 'could not connect to database %s' from
scripts/common.c.


-- 
Euler Taveira                 http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  3. Re: redundant error messages

    Isaac Morland <isaac.morland@gmail.com> — 2020-11-05T14:49:32Z

    On Thu, 5 Nov 2020 at 08:34, Euler Taveira <euler.taveira@2ndquadrant.com>
wrote:

Is the database name important for this message? You should inform which
> database you want to connect for all client tools except pg_dumpall.
> Hence, you
> already know which database has the connection problem. IMO the pg_dumpall
> message should inform the database name. My suggestion is:
>

In principle, the client knows the database name. In practice, if it's
coming from PGDATABASE or via a service configuration, one may be confused
about the database; having the error message be explicit will avoid many
problems. I can easily imagine that "unable to connect to database" would
be mystifying, whereas "unable to connect to database foo" would elicit the
response, "wait, I'm trying to connect to what now?" leading much more
quickly to a resolution.

  4. Re: redundant error messages

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2020-11-05T15:53:56Z

    On 2020-Nov-05, Isaac Morland wrote:

> In principle, the client knows the database name. In practice, if it's
> coming from PGDATABASE or via a service configuration, one may be confused
> about the database; having the error message be explicit will avoid many
> problems. I can easily imagine that "unable to connect to database" would
> be mystifying, whereas "unable to connect to database foo" would elicit the
> response, "wait, I'm trying to connect to what now?" leading much more
> quickly to a resolution.

Also consider cases like running something via cron, where the person
reading the error output does not necessarily know what command is being
run: it might be hidden inside a script.  It's often very helpful to
have object names in error messages, even if for the normal usage it
seems that the object being operated on is very obvious by just looking
at the command.

  5. Re: redundant error messages

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2020-11-07T22:15:08Z

    On 2020-11-05 13:27, Peter Eisentraut wrote:
> A few client tools duplicate error messages already provided by libpq,
> such as
> 
> pg_rewind: fatal: could not connect to server: could not connect to
> server: No such file or directory
> 
> pg_basebackup: error: could not connect to server: could not connect to
> server: No such file or directory
> 
> psql: error: could not connect to server: could not connect to server:
> No such file or directory
> 
> The psql case is actually a regression introduced in PG12, but the other
> two appear to be ancient.

I have committed fixes for these.