Re: pg_waldump stucks with options --follow or -f and --stats or -z

On Tue, Nov 16, 2021 at 09:34:25AM +0530, Bharath Rupireddy wrote:
> It looks okay to be more responsive with the -f option so that the
> above commands keep emitting stats for every 1 second(the --follow
> option waits for 1 second). Should we really be emitting stats for
> every 1 second? Isn't there going to be too much information on the
> stdout? Or should we be emitting the stats for every 5 or 10 seconds?

I don't have a perfect answer to this question, but dumping the stats
with a fixed frequency is not going to be useful if we don't have in
those logs a current timestamp and/or a current LSN. This is
basically about how much we want to call XLogDumpDisplayStats() and
how useful it is, but note that my argument is a bit different than
what you are describing here: we could try to make
XLogDumpDisplayStats() responsive on SIGINT or SIGTERM to show
statistics reports. This way, a --follow without an --end LSN
specified could still provide some information rather than nothing.
That could also be useful if defining an --end but interrupting the
call.

At the same time, we could also just let things as they are. --follow
and --stats being specified together is what the user looked for, so
they get what they wanted.

> In summary, we have the following options:
> 1) block the combinations "-s/-f/-z", "-s/-e/-f/-z"
> 2) be more responsive and keep emitting the stats per 1 sec default
> with -f option
> 3) be more responsive and keep emitting the stats per user's choice
> of seconds (a new option that can be used with the -s/-e/-f/-z).

A frequency cannot be measured only in time here, but also in bytes in
terms of a minimum amount of WAL replayed between two reports. I
don't like much the idea of multiple stats reports emitted in a single
pg_waldump call, TBH. This makes things more complicated than they
should, and the gain is not obvious, at least to me.
--
Michael