Re: Use of backup_label not noted in log
От | David Steele |
---|---|
Тема | Re: Use of backup_label not noted in log |
Дата | |
Msg-id | 87bb6850-1a9c-4f78-948e-44efade98443@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Use of backup_label not noted in log (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Use of backup_label not noted in log
|
Список | pgsql-hackers |
On 11/17/23 01:41, Laurenz Albe wrote: > 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 I think a backpatch is OK as long as it is a separate message, but I like your idea of adding to the "redo starts" message going forward. I know this isn't really a bug, but not being able to tell where recovery information came from seems like a major omission in the logging. Regards, -David
В списке pgsql-hackers по дате отправления: