Thread: redundant error messages
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.
Attachment
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.
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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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.
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.
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.