Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Tue, 2020-06-30 at 17:38 -0400, David Steele wrote: > > Rebased patch is attached. > > I remain -1 on removing the exclusive backup API.
It's still deprecated and I'm certainly against removing that status until/unless someone actually fixes it (including documentation), and if we're not going to do that then we should remove it. > People who don't mind manual intervention when PostgreSQL doesn't > start after a crash in backup mode could safely use it. I disagree that that's really appropriate. > We have been over this, and there is not much point in re-opening > the discussion. I just had to speak up. It's not ok to just leave it as deprecated forever. > > Lastly, there is some concern about getting the backup label too late > > when doing snapshots or using traditional backup software. It would > > certainly be possible to return the backup_label and tablespace_map from > > pg_start_backup() and let the user make the choice about what to do with > > them. Any of these methods will require some scripting so I don't see > > why the files couldn't be written as, for example, backup_label.snap and > > tablespace_map.snap and then renamed by the restore script. The patch > > does not currently make this change, but it could be added pretty easily > > if that overcomes this objection. > > That would be interesting improvements that would make the non-exclusive > backup API easier to use. This would presumably be for the exclusive API as a way to make it not completely broken, maybe. If we wanted to try and make this work in a non-exclusive manner then we'd need to do something like have the user save some info out at pg_start_backup time that they then provide at pg_stop_backup time, so we can match up the specific backup and write the appropriate WAL message. Thanks, Stephen
signature.asc
Description: PGP signature
