Re: pgbench -i progress output on terminal - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pgbench -i progress output on terminal
Date
Msg-id 20191202062844.GG1696@paquier.xyz
Whole thread Raw
In response to Re: pgbench -i progress output on terminal  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: pgbench -i progress output on terminal  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pgbench -i progress output on terminal  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Mon, Dec 02, 2019 at 02:30:47PM +0900, Amit Langote wrote:
> On Sun, Dec 1, 2019 at 4:33 AM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>> Patch applies, compiles, works for me. No further comments.
>>
>> I switched the patch as ready.
>
> Thanks a lot.

An issue with the patch as proposed is that its style is different
than what pg_rewind and pg_basebackup do in the same cases, but who
cares :)

By the way, the first patch sent on this thread had a bug when
redirecting the output of stderr to a log file because it was printing
a newline for each loop done on naccounts, but you just want to print
a log every 100 rows or 100k rows depending on if the quiet mode is
used or not, so the log file grew in size with mostly empty lines.  v3
does that correctly of course as you add the last character of one log
line each time the log entry is printed.

Another question I have is why doing only that for the data
initialization phase?  Wouldn't it make sense to be consistent with
the other tools having --progress and do the same dance in pgbench's
printProgressReport()?

NB: Note as well that pgindent complains for one thing, a newline
before the call to isatty.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Add a GUC variable that control logical replication
Next
From: Haozhou Wang
Date:
Subject: Re: Control your disk usage in PG: Introduction to Disk Quota Extension