Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Дата
Msg-id CALj2ACWB9o5pQ0OWbndNxUVLX9SQ2ys5sOWerPok-XUsnoY+dA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display  (Michael Paquier <michael@paquier.xyz>)
Список 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.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?