Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Michael Paquier]

On Wed, Aug 16, 2017 at 9:29 AM, Peter Eisentraut
 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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Peter Eisentraut]

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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Michael Paquier]

On Sun, Jul 9, 2017 at 9:30 PM, Michael Paquier
 wrote:
> On Sun, Jul 9, 2017 at 5:58 AM, Magnus Hagander  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


receivewal-verbose-fix-v2.patch
Description: Binary data

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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Michael Paquier]

On Sun, Jul 9, 2017 at 5:58 AM, Magnus Hagander  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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Magnus Hagander]

On Wednesday, June 14, 2017, Michael Paquier 
wrote:

> On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer  > wrote:
> > On 13 June 2017 at 14:33, Michael Paquier  > 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/ 
 Work: https://www.redpill-linpro.com/ 

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Daniel Gustafsson]

> On 14 Jun 2017, at 06:04, Michael Paquier  wrote:
> 
> On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer  wrote:
>> On 13 June 2017 at 14:33, Michael Paquier  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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Michael Paquier]

On Tue, Jun 13, 2017 at 4:50 PM, Craig Ringer  wrote:
> On 13 June 2017 at 14:33, Michael Paquier  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


receivewal-verbose-fix.patch
Description: Binary data

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

Re: [HACKERS] pg_receivewal and messages printed in non-verbose mode

[Craig Ringer]

On 13 June 2017 at 14:33, Michael Paquier  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

[HACKERS] pg_receivewal and messages printed in non-verbose mode

[Michael Paquier]

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.

Thanks,
-- 
Michael


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