From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, 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-17 05:41:46 |
Message-ID: | c277c9736ec951776aa11a8ca95b60aaffbe8b8d.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2023-11-16 at 20:18 -0800, Andres Freund wrote:
> I've often had to analyze what caused corruption in PG instances, where the
> symptoms match not having had backup_label in place when bringing on the
> node. However that's surprisingly hard - the only log messages that indicate
> use of backup_label are at DEBUG1.
>
> Given how crucial use of backup_label is and how frequently people do get it
> wrong, I think we should add a LOG message - it's not like use of backup_label
> is a frequent thing in the life of a postgres instance and is going to swamp
> the log. And I think we should backpatch that addition.
+1
I am not sure about the backpatch: it is not a bug, and we should not wantonly
introduce new log messages in a minor release. Some monitoring system may
get confused.
What about adding it to the "redo starts at" message, something like
redo starts at 12/12345678, taken from control file
or
redo starts at 12/12345678, taken from backup label
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-11-17 06:41:12 | Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 |
Previous Message | Nathan Bossart | 2023-11-17 04:38:22 | Re: Hide exposed impl detail of wchar.c |