On Wed, Dec 01, 2021 at 11:44:02AM +0530, Bharath Rupireddy wrote:
> Here's the v6 patch that has the SIGINT handling enabled for non-WIN32
> platforms (note that I haven't specified anything in the
> documentation) much like pg_receivewal and pg_recvlogical.
I have added a safeguard in
On Mon, Nov 29, 2021 at 1:16 PM Bharath Rupireddy
wrote:
>
> On Mon, Nov 29, 2021 at 11:09 AM Michael Paquier wrote:
> >
> > On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> > > Thanks. Here's the v5.
> >
> > By the way, one thing that I completely forgot here is that SIGINT
On Mon, Nov 29, 2021 at 11:09 AM Michael Paquier wrote:
>
> On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> > Thanks. Here's the v5.
>
> By the way, one thing that I completely forgot here is that SIGINT is
> not handled on Windows. If we want to make that work for a WIN32
>
On Sun, Nov 28, 2021 at 12:13:08PM +0530, Bharath Rupireddy wrote:
> Thanks. Here's the v5.
By the way, one thing that I completely forgot here is that SIGINT is
not handled on Windows. If we want to make that work for a WIN32
terminal, we would need to do something similar to
On Sun, Nov 28, 2021 at 9:50 AM Michael Paquier wrote:
> v4 is just moving this paragraph in its correct subsection. My
> wording may have been confusing here, sorry about that. What I meant
> is that there is no need to mention --follow at all, as an
> interruption done before reaching the end
On Fri, Nov 26, 2021 at 03:47:30PM +0530, Bharath Rupireddy wrote:
> On Fri, Nov 26, 2021 at 11:50 AM Michael Paquier wrote:
>> +When --follow is used with --stats and
>> +the pg_waldump is terminated or interrupted
>> +with signal SIGINT or
>> SIGTERM
>> +or SIGQUIT, the summary
On Fri, Nov 26, 2021 at 11:50 AM Michael Paquier wrote:
>
> 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,
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,
On Sat, Nov 20, 2021 at 11:10 AM Michael Paquier wrote:
> What you should do is to set such a flag in the signal handler, and
> then check its value in the main loop of pg_waldump, dumping the stats
> if it is detected as turned on because of a signal.
Thanks. Here's the v3 patch, a much simpler
On Sat, Nov 20, 2021 at 10:03:27AM +0530, Bharath Rupireddy wrote:
> Here's the v2 patch with the above changes i.e. pg_waldump now eimits
> the computed stats at the time of termination. Please review it.
+#define MAX_XLINFO_TYPES 16
+#define fatal_error(...) do { pg_log_fatal(__VA_ARGS__);
On Thu, Nov 18, 2021 at 2:03 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 18, 2021 at 1:51 PM Michael Paquier wrote:
> >
> > On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> > > Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> > > and then it should emit
On Thu, Nov 18, 2021 at 1:51 PM Michael Paquier wrote:
>
> On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> > Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> > and then it should emit the computed stats in those handlers the
> > comobinations -
On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> and then it should emit the computed stats in those handlers the
> comobinations - "-s/-f/-z" and "-s/-e/-f/-z". I'm okay with this
> behaviour. Michael
On Thu, Nov 18, 2021 at 12:05 AM Alvaro Herrera wrote:
>
> On 2021-Nov-17, Bharath Rupireddy wrote:
>
> > On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
> > >
> > > At the same time, we could also just let things as they are. --follow
> > > and --stats being specified together is what
On 2021-Nov-17, Bharath Rupireddy wrote:
> On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
> >
> > 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.
>
> I think
On Wed, Nov 17, 2021 at 7:49 AM Michael Paquier wrote:
>
> 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.
I think the existing way of pg_waldump getting stuck with the
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
On Tue, Nov 16, 2021 at 8:26 AM Michael Paquier wrote:
>
> 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
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
Hi,
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
20 matches
Mail list logo
