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

From Fabien COELHO
Subject Re: pgbench - use pg logging capabilities
Date
Msg-id alpine.DEB.2.21.2001031213190.3482@pseudo
Whole thread Raw
In response to Re: pgbench - use pg logging capabilities  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: pgbench - use pg logging capabilities
List pgsql-hackers
Hello Peter,

>> 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.

Indeed. It was when I used "debug" as a shorthand for "pg_log_debug".

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

Without looking at the context I thought that argv[0] was the program 
name, which is not the case here. I put it back everywhere, including the 
DEBUG message.

> 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.

Ok.

> -       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.

Ok. I homogeneised another similar message.

Patch v3 attached hopefully fixes all of the above.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: sidewinder has one failure
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - allow to create partitioned tables