Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Date
Msg-id YZMh71bIIy6lOGM1@paquier.xyz
Whole thread Raw
In response to Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
List pgsql-hackers
On Mon, Nov 15, 2021 at 10:36:09PM +0000, Bossart, Nathan wrote:
> +    ereport(DEBUG1,
> +            (errmsg_internal("executing archive command \"%s\" for archving %s",
> +                             xlogarchcmd, xlog)));
>
> I wonder if it's necessary to include the "for archiving" part in this
> one.  Typically, the xlogarchcmd will include it somewhere.

Don't see any need to add that either (s/archving/archiving/, btw).

@@ -1000,6 +1004,10 @@ XLogWalRcvFlush(bool dying, TimeLineID tli)
+               ereport(DEBUG1,
+                               (errmsg_internal("streaming %X/%X",
+ LSN_FORMAT_ARGS(LogstreamResult.Write))));
Having the same wording for the WAL receiver and the WAL sender could
be confusing when it comes to a cascading standby node, particularly
if log_line_prefix does not include the process PID.

+       ereport(DEBUG1,
+                       (errmsg_internal("streaming %X/%X",
+                                                         LSN_FORMAT_ARGS(sentPtr))));
Anyway, those two ones are going to make the logs much more noisy, no?
The same could be said about XLogFileRead(), joining the point of
Nathan's upthread.  So I cannot get excited by this change.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Frontend error logging style
Next
From: Tatsuro Yamada
Date:
Subject: Re: Add psql command to list constraints