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

From Michael Paquier
Subject Re: pgbench - use pg logging capabilities
Date
Msg-id 20200102133741.GA3422@paquier.xyz
Whole thread Raw
In response to Re: pgbench - use pg logging capabilities  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Wed, Jan 01, 2020 at 10:19:52PM +0100, Fabien COELHO wrote:
> Bonjour Michaël, et excellente année 2020 !

Toi aussi!  Bonne année.

>> Hmm.  Wouldn't it make sense to output the log generated as
>> information from the test using pg_log_info() instead of using
>> fprintf(stderr) (the logs of the initial data load, progress report)?
>
> For the progress report, the reason I decided against is that the lines are
> already long enough with data (for the progress report: tps, latency, etc.),
> and prepending "pgbench info" or equivalent in front of every line does not
> look very useful and make it more likely that actually useful data could be
> pushed out of the terminal width.

Hm.  Okay.  That would limit the patch to only report errors in the
first round of changes, which is fine by me.

> For data load, ISTM that people are used to it like that. Moreover, I do not
> think that the \r recently-added trick can work with the logging stuff, so I
> left it out as well altogether.

It could be possible to create new custom options for logging.c.  We
already have one as of PG_LOG_FLAG_TERSE to make the output of psql
compatible with regression tests and such.  These are just thoughts
about the control of:
- the progname is appended to the error string or not.
- CR/LF as last character.

> Dunno about translation. ISTM that pgbench is mostly not translated, not
> sure why.

Because as a benchmark tool that's not really worth it and its output
is rather technical hence translating it would be more challenging?
Perhaps others more used to translation work could chime in the
discussion?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Refactor parse analysis of EXECUTE command
Next
From: Guillaume Lelarge
Date:
Subject: Re: parallel vacuum options/syntax