From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-26 06:20:08 |
Message-ID: | YaB8mLRRyA0DWnzY@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 20, 2021 at 11:46:35AM +0530, Bharath Rupireddy wrote:
> Thanks. Here's the v3 patch, a much simpler one. Please review it.
+ pqsignal(SIGINT, SignalHandlerForTermination);
+ pqsignal(SIGTERM, SignalHandlerForTermination);
+ pqsignal(SIGQUIT, SignalHandlerForTermination);
FWIW, I think that we should do this stuff only on SIGINT. I would
imagine that this behavior becomes handy mainly when one wishes to
Ctrl+C the terminal running pg_waldump but still get some
information.
XLogDumpCountRecord(&config, &stats, xlogreader_state);
+ stats.endptr = xlogreader_state->currRecPtr;
Isn't what you are looking for here EndRecPtr rather than currRecPtr,
to track the end of the last record read?
+ When <option>--follow</option> is used with <option>--stats</option> and
+ the <application>pg_waldump</application> is terminated or interrupted
+ with signal <systemitem>SIGINT</systemitem> or <systemitem>SIGTERM</systemitem>
+ or <systemitem>SIGQUIT</systemitem>, the summary statistics computed
+ as of the termination will be displayed.
This description is not completely correct, as the set of stats would
show up only by using --stats, in non-quiet mode. Rather than
describing this behavior at the end of the docs, I think that it would
be better to add a new paragraph in the description of --stats.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2021-11-26 06:31:24 | Re: row filtering for logical replication |
Previous Message | Richard Guo | 2021-11-26 06:09:50 | Inconsistent results from seqscan and gist indexscan |