Re: pgbench - use pg logging capabilities - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pgbench - use pg logging capabilities
Date
Msg-id 4763a276-149c-927c-f8d1-7a53a9610bd3@2ndquadrant.com
Whole thread Raw
In response to Re: pgbench - use pg logging capabilities  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: pgbench - use pg logging capabilities
List pgsql-hackers
On 2020-01-01 22:55, Fabien COELHO wrote:
> I'm trying to keep the column width under control, but if you like it
> wider, here it is.
> 
> Compared to v1 I have also made a few changes to be more consistent when
> using fatal/error/info.

The renaming of debug to debug_level seems unnecessary and unrelated.

In runShellCommand(), you removed some but not all argv[0] from the 
output messages.  I'm not sure what the intent was there.

I would also recommend these changes:

-       pg_log_fatal("query failed: %s", sql);
-       pg_log_error("%s", PQerrorMessage(con));
+       pg_log_fatal("query failed: %s", PQerrorMessage(con));
+       pg_log_info("query was: %s", sql);

This puts the most important information first.

-       pg_log_error("connection to database \"%s\" failed", dbName);
-       pg_log_error("%s", PQerrorMessage(conn));
+       pg_log_error("connection to database \"%s\" failed: %s",
+                    dbName, PQerrorMessage(conn));

Line break here is unnecessary.

In both cases, pg_dump has similar messages that can serve as reference.

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pgbench - allow to create partitioned tables
Next
From: Surafel Temesgen
Date:
Subject: Re: WIP: System Versioned Temporal Table