Re: Use of backup_label not noted in log

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: Use of backup_label not noted in log
Date: 2023-11-20 10:35:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.

Laurenz Albe

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-11-20 10:51:47 Re: Inquiry on Generating Bitmaps from Filter Conditions in Index Scans
Previous Message Peter Eisentraut 2023-11-20 10:21:41 Re: should check collations when creating partitioned index