pg_receivewal and messages printed in non-verbose mode

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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
<javascript:;>> wrote:

On 13 June 2017 at 14:33, Michael Paquier <michael.paquier@gmail.com

<javascript:;>> 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

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers