Re: pgbench - use pg logging capabilities
| От | Peter Eisentraut |
|---|---|
| Тема | Re: pgbench - use pg logging capabilities |
| Дата | |
| Msg-id | 4763a276-149c-927c-f8d1-7a53a9610bd3@2ndquadrant.com обсуждение исходный текст |
| Ответ на | Re: pgbench - use pg logging capabilities (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: pgbench - use pg logging capabilities
|
| Список | 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 по дате отправления: