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