From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: Use of backup_label not noted in log |
Date: | 2023-11-18 13:26:40 |
Message-ID: | 241ccde1-1928-4ba2-a0bb-5350f7b191a8@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/17/23 00:18, 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 for the message and I think a backpatch is fine as long as it is a
new message. If monitoring systems can't handle an unrecognized message
then that feels like a problem on their part.
> Medium term I think we should go further, and leave evidence in pg_control
> about the last use of ControlFile->backupStartPoint, instead of resetting it.
Michael also thinks this is a good idea.
> I realize that there's a discussion about removing backup_label - but I think
> that's fairly orthogonal. Should we go with the pg_control approach, we should
> still emit a useful message when starting in a state that's "equivalent" to
> having used the backup_label.
Agreed, this new message could easily be adapted to the recovery in
pg_control patch.
Regards,
-David
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2023-11-18 13:27:40 | Re: Schema variables - new implementation for Postgres 15 |
Previous Message | Pavel Stehule | 2023-11-18 13:25:41 | Re: Schema variables - new implementation for Postgres 15 |