Thread: [PATCH] Allow usage of archive .backup files as backup_label
Hi, The .backup files written to the archive (if archiving is on) are very similar to the backup_label that's written/returned by pg_stop_backup()/pg_backup_stop(), they just have a few extra lines about the end of backup process that are missing from backup_label. The parser in xlogrecovery.c however barfs on them because it does not expect the additional STOP WAL LOCATION on line 2. The attached makes parsing this line optional, so that one can use those .backup files in place of backup_label. This is e.g. useful if the backup_label got lost or the output of pg_stop_backup() was not captured. Michael -- Team Lead PostgreSQL Project Manager Tel.: +49 2166 9901-171 Mail: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Management: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Our handling of personal data is subject to: https://www.credativ.de/en/contact/privacy/
Attachment
On Mon, Aug 22, 2022 at 05:16:58PM +0200, Michael Banck wrote: > The .backup files written to the archive (if archiving is on) are very > similar to the backup_label that's written/returned by > pg_stop_backup()/pg_backup_stop(), they just have a few extra lines > about the end of backup process that are missing from backup_label. Historically, there is "STOP WAL LOCATION" after "START WAL LOCATION", and "STOP TIME"/"STOP TIMELINE" at the end. > The parser in xlogrecovery.c however barfs on them because it does not > expect the additional STOP WAL LOCATION on line 2. Hm, no. I don't think that I'd want to expand the use of the backup history file in the context of recovery, so as we are free to add any extra information into it if necessary without impacting the compatibility of the recovery code. This file is primarily here for debugging, so I'd rather let it be used only for this purpose. Opinions of others are welcome, of course. -- Michael
Attachment
On Tue, 2022-10-18 at 10:55 +0900, Michael Paquier wrote: > On Mon, Aug 22, 2022 at 05:16:58PM +0200, Michael Banck wrote: > > The .backup files written to the archive (if archiving is on) are very > > similar to the backup_label that's written/returned by > > pg_stop_backup()/pg_backup_stop(), they just have a few extra lines > > about the end of backup process that are missing from backup_label. > > Historically, there is "STOP WAL LOCATION" after "START WAL LOCATION", > and "STOP TIME"/"STOP TIMELINE" at the end. > > > The parser in xlogrecovery.c however barfs on them because it does not > > expect the additional STOP WAL LOCATION on line 2. > > Hm, no. I don't think that I'd want to expand the use of the backup > history file in the context of recovery, so as we are free to add any > extra information into it if necessary without impacting the > compatibility of the recovery code. This file is primarily here for > debugging, so I'd rather let it be used only for this purpose. > Opinions of others are welcome, of course. I tend to agree with you. It is easy to break PostgreSQL by manipulating or removing "backup_label", and copying a file from the WAL archive and renaming it to "backup_label" sounds like a footgun of the first order. There is nothing that prevents you from copying the wrong file. Such practices should not be encouraged. Anybody who knows enough about PostgreSQL to be sure that what they are doing is correct should be smart enough to know how to edit the copied file. Yours, Laurenz Albe
On Tue, Oct 18, 2022 at 04:55:46AM +0200, Laurenz Albe wrote: > I tend to agree with you. It is easy to break PostgreSQL by manipulating > or removing "backup_label", and copying a file from the WAL archive and > renaming it to "backup_label" sounds like a footgun of the first order. > There is nothing that prevents you from copying the wrong file. > Such practices should not be encouraged. > > Anybody who knows enough about PostgreSQL to be sure that what they are > doing is correct should be smart enough to know how to edit the copied file. A few weeks after, still the same thoughts on the matter, so please note that I have marked that as rejected in the CF app. If somebody wants to offer more arguments for this thread, of course please feel free. -- Michael