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.2001012212120.23377@pseudo
Whole thread Raw
In response to Re: pgbench - use pg logging capabilities  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgbench - use pg logging capabilities  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Bonjour Michaël, et excellente année 2020 !

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

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 seems to me that this would be consistent with the other tools we
> have, and being able to make a difference with the level of logs is
> kind of a nice property of logging.c as you can grep easily for one
> problems instead of looking at multiple patterns matching an error in
> the logs.  Note also an error in the scripts does not report an
> error.  Another thing is that messages logged would need to be
> translated.  I think that's nice, but perhaps others don't like that
> or may think that's not a good idea.  Who knows..

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

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: WIP: System Versioned Temporal Table
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - use pg logging capabilities