Re: Use of backup_label not noted in log

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Use of backup_label not noted in log
Дата
Msg-id 67c6cea866ee7aeb324008341a8c697151146a9d.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Use of backup_label not noted in log  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Use of backup_label not noted in log  (David Steele <david@pgmasters.net>)
Re: Use of backup_label not noted in log  (Robert Haas <robertmhaas@gmail.com>)
Re: Use of backup_label not noted in log  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
I can accept that adding log messages to back branches is ok.
Perhaps I am too nervous about things like that, because as an extension
developer I have been bitten too often by ABI breaks in minor releases
in the past.

On Mon, 2023-11-20 at 17:30 +0900, Michael Paquier wrote:
> +       if (ControlFile->backupStartPoint != InvalidXLogRecPtr)
> +           ereport(LOG,
> +                   (errmsg("continuing to start from base backup with redo LSN %X/%X",
> +                           LSN_FORMAT_ARGS(ControlFile->backupStartPoint))));
>
> "Continuing to start" sounds a bit weird to me, though, considering
> that there are a few LOGs that say "starting" when there is a signal
> file, but I don't have a better idea on top of my mind.  So that
> sounds OK here.

We can only reach that message in recovery or standby mode, right?
So why not write "continuing to recover from base backup"?


If we add a message for starting with "backup_label", shouldn't
we also add a corresponding message for starting from a checkpoint
found in the control file?  If you see that in a problem report,
you immediately know what is going on.

Yours,
Laurenz Albe



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: should check collations when creating partitioned index
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Inquiry on Generating Bitmaps from Filter Conditions in Index Scans