Re: pgbench - use pg logging capabilities

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - use pg logging capabilities
Date: 2020-01-02 13:37:41
Message-ID: 20200102133741.GA3422@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2020-01-02 13:39:20 Re: parallel vacuum options/syntax
Previous Message Pavel Stehule 2020-01-02 13:26:04 Re: Refactor parse analysis of EXECUTE command