|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: pgbench - use pg logging capabilities|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Fabien COELHO||2020-01-01 21:55:29||Re: pgbench - use pg logging capabilities|
|Previous Message||Vik Fearing||2020-01-01 21:12:09||Re: WIP: System Versioned Temporal Table|