From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net> |
Subject: | Use of backup_label not noted in log |
Date: | 2023-11-17 04:18:11 |
Message-ID: | 20231117041811.vz4vgkthwjnwp2pp@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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.
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.
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.
Thoughts?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2023-11-17 04:20:04 | Re: Synchronizing slots from primary to standby |
Previous Message | Laurenz Albe | 2023-11-17 03:53:31 | Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 |