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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_waldump stucks with options --follow or -f and --stats or -z
Date: 2021-11-16 02:56:01
Message-ID: YZMdwWlzESUoCGjH@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 15, 2021 at 07:32:38PM +0530, Bharath Rupireddy wrote:
> pg_waldump options, --follow or -f(to keep polling once per second for
> new WAL to appear) and --stats or -z don't work well together i.e. the
> command stucks [1]. I think the pg_waldump should emit an error. Note
> that the pg_basebakup does error out on incompatible options.
>
> Here's a small patch for fixing above along with a note in the documentation.
>
> Thoughts?

I don't think that we should block this combination of options as you
are proposing. The existing behavior is useful for users when it
comes to an end position specified with -e, to be able to gather some
stats on a cluster or an archive where we may not have all the
contents wanted yet.

> [1] The following commands stuck:
> ./pg_waldump -p data/ -s 0/7000060 -f -z
> ./pg_waldump -p data/ -s 0/7000060 -f --stats='record'
> ./pg_waldump -p data/ -s 0/7000060 -f --stats='rmgr'

Saying that, you are not completely wrong either, as following
something while we won't print any stats at all is not really
helpful. Another thing I can think of here is to make pg_waldump
more responsive to the dump of the stats when interrupted, via
XLogDumpDisplayStats().
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-11-16 03:02:08 Re: Frontend error logging style
Previous Message David G. Johnston 2021-11-16 02:49:27 Re: Add psql command to list constraints