Greetings,
* Laurenz Albe (laurenz.albe@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