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

From Bharath Rupireddy
Subject Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Date
Msg-id CALj2ACWB9o5pQ0OWbndNxUVLX9SQ2ys5sOWerPok-XUsnoY+dA@mail.gmail.com
Whole thread Raw
In response to Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display  (Michael Paquier <michael@paquier.xyz>)
Responses Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Dec 8, 2021 at 2:08 PM Michael Paquier <michael@paquier.xyz> wrote:
> > Do you want me to add "received from stream" in general?
>
> "from stream" would be fine, IMHO.

Done in the attached v5 patch.

> > How about we invent a new GUC log_recovery, with default set to false,
> > similar to log_checkpoints? And, these messages can be like:
> > ereport(log_recovery ? LOG : DEBUG1, .....)? This GUC can be useful to
> > add some recovery stats in future as well. Thoughts?
>
> This discussion does not justify a new GUC at this stage IMO.

Having "log_recovery" GUC gives the flexibility to the users to enable
the recovery logs added by this patch if they are concerned otherwise
the logs just be at DEBUG1 level. Setting log_min_messages level to
DEBUG1 would definitely flood the server logs.

> While quickly testing, I got reminded that the LOG for a segment
> retrieved from the local pg_wal would generate some noise when running
> for example the bootstrap process.  Is this one really interesting
> compared to the two others?

If we just have the archive related message at LOG level and others at
DEBUG1 level, it is a kind of partial recovery log information that
one has in the log files, missing recovery messages from the pg_wal
directory in the logs.

Another option is to just have all the messages (added in the patch)
at DEBUG1 level, let's users deal with it.

IMO, the new GUC "log_recovery" is way better as it can be extended to
include some recovery stats info as well.

Thoughts?

Regards,
Bharath Rupireddy.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Bharath Rupireddy
Date:
Subject: Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?