Thread: [HACKERS] pg_receivewal and messages printed in non-verbose mode
Hi all, I have noticed that the following messages can show up from pg_receivewal even if the verbose mode is not used: if (prevtimeline != 0 && prevtimeline != timeline) fprintf(stderr, _("%s: switched to timeline %u at %X/%X\n"), progname, timeline, (uint32) (prevpos >> 32), (uint32) prevpos); if (time_to_abort) { fprintf(stderr,_("%s: received interrupt signal, exiting\n"), progname); returntrue; } Those come from stop_streaming in pg_receivewal.c. Shouldn't those messages only show up to the user if --verbose is used? It seems strange to me that at least the first one is written to the user as that's not an error after promoting a standby. Thanks, -- Michael
On 13 June 2017 at 14:33, Michael Paquier <michael.paquier@gmail.com> wrote: > Hi all, > > I have noticed that the following messages can show up from > pg_receivewal even if the verbose mode is not used: > if (prevtimeline != 0 && prevtimeline != timeline) > fprintf(stderr, _("%s: switched to timeline %u at %X/%X\n"), > progname, timeline, > (uint32) (prevpos >> 32), (uint32) prevpos); > if (time_to_abort) > { > fprintf(stderr, _("%s: received interrupt signal, exiting\n"), > progname); > return true; > } > Those come from stop_streaming in pg_receivewal.c. Shouldn't those > messages only show up to the user if --verbose is used? It seems > strange to me that at least the first one is written to the user as > that's not an error after promoting a standby. I agree. At least the first should be --verbose only. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 13 June 2017 at 14:33, Michael Paquier <michael.paquier@gmail.com> wrote: >> Those come from stop_streaming in pg_receivewal.c. Shouldn't those >> messages only show up to the user if --verbose is used? It seems >> strange to me that at least the first one is written to the user as >> that's not an error after promoting a standby. > > I agree. At least the first should be --verbose only. I have been looking at all the code surrounding pg_receivewal and pg_recvlogical and those are indeed the two only places where we print a message in non-verbose mode even if those are not explicit errors. pg_recvlogical does not show up any messages when it is signaled or when it receives SIGINT or reaches the end of LSN position. I don't think that this is worth complicating the code for, just noticed the inconsistency on the way. Perhaps a committer will care about that. Or not. For now I am just adding that in the CF. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
> On 14 Jun 2017, at 06:04, Michael Paquier <michael.paquier@gmail.com> wrote: > > On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer <craig@2ndquadrant.com> wrote: >> On 13 June 2017 at 14:33, Michael Paquier <michael.paquier@gmail.com> wrote: >>> Those come from stop_streaming in pg_receivewal.c. Shouldn't those >>> messages only show up to the user if --verbose is used? It seems >>> strange to me that at least the first one is written to the user as >>> that's not an error after promoting a standby. >> >> I agree. At least the first should be --verbose only. > > I have been looking at all the code surrounding pg_receivewal and > pg_recvlogical and those are indeed the two only places where we print > a message in non-verbose mode even if those are not explicit errors. > pg_recvlogical does not show up any messages when it is signaled or > when it receives SIGINT or reaches the end of LSN position. I don't > think that this is worth complicating the code for, just noticed the > inconsistency on the way. > > Perhaps a committer will care about that. Or not. For now I am just > adding that in the CF. +1, this patch makes --verbose behave consistently across these programs. Since Ctrl-C’ing the program to terminate is not an error, I agree that it should require verbose mode too. I took a look as well and concur with your findings. Moving to Ready for Committer. cheers ./daniel
On Wednesday, June 14, 2017, Michael Paquier <michael.paquier@gmail.com> wrote:
--
On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 13 June 2017 at 14:33, Michael Paquier <michael.paquier@gmail.com> wrote:
>> Those come from stop_streaming in pg_receivewal.c. Shouldn't those
>> messages only show up to the user if --verbose is used? It seems
>> strange to me that at least the first one is written to the user as
>> that's not an error after promoting a standby.
>
> I agree. At least the first should be --verbose only.
I have been looking at all the code surrounding pg_receivewal and
pg_recvlogical and those are indeed the two only places where we print
a message in non-verbose mode even if those are not explicit errors.
pg_recvlogical does not show up any messages when it is signaled or
when it receives SIGINT or reaches the end of LSN position. I don't
think that this is worth complicating the code for, just noticed the
inconsistency on the way.
Perhaps a committer will care about that. Or not. For now I am just
adding that in the CF.
I agree that this should be fixed.
I wonder if we should actually just remove the second message? AFAICT no other tools log that information. Is there any particular reason why we want that logging in pg_receivewal when we don't have it in other tools?
//Magnus
--
On Sun, Jul 9, 2017 at 5:58 AM, Magnus Hagander <magnus@hagander.net> wrote: > I wonder if we should actually just remove the second message? AFAICT no > other tools log that information. Is there any particular reason why we want > that logging in pg_receivewal when we don't have it in other tools? I maintain a fork of pg_receivewal lately that works as a service, and I have found myself a fan of this log bit when debugging funky issues. That's a personal opinion, no objections to remove it either. -- Michael
On Sun, Jul 9, 2017 at 9:30 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sun, Jul 9, 2017 at 5:58 AM, Magnus Hagander <magnus@hagander.net> wrote: >> I wonder if we should actually just remove the second message? AFAICT no >> other tools log that information. Is there any particular reason why we want >> that logging in pg_receivewal when we don't have it in other tools? > > I maintain a fork of pg_receivewal lately that works as a service, and > I have found myself a fan of this log bit when debugging funky issues. > That's a personal opinion, no objections to remove it either. The patch I sent upthread was actually doing that, which is obviously incorrect: - if (time_to_abort) + if (verbose && time_to_abort) { fprintf(stderr, _("%s: received interrupt signal, exiting\n"), progname); While the version on my laptop does that: if (time_to_abort) { - fprintf(stderr, _("%s: received interrupt signal, exiting\n"), - progname); + if (verbose) + fprintf(stderr, _("%s: received interrupt signal, exiting\n"), + progname); return true; } return false; Not sure how that feel into the cracks. I slept on it, and let's do things the same way as the other tools do without logs in this case. So this gives the patch attached. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On 7/9/17 22:08, Michael Paquier wrote: > While the version on my laptop does that: > if (time_to_abort) > { > - fprintf(stderr, _("%s: received interrupt signal, exiting\n"), > - progname); > + if (verbose) > + fprintf(stderr, _("%s: received interrupt > signal, exiting\n"), > + progname); > return true; > } > return false; > Not sure how that feel into the cracks. I have committed that version. I think the exit message can be useful, because pg_receivewal will usually run as some kind of background process where the exit status might be not be visible. I have also committed a small documentation patch to describe the exit status and behavior better. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Aug 16, 2017 at 9:29 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > I have committed that version. I think the exit message can be useful, > because pg_receivewal will usually run as some kind of background > process where the exit status might be not be visible. Thanks. > I have also committed a small documentation patch to describe the exit > status and behavior better. That looks fine to me. -- Michael