Обсуждение: [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

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

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

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