On Tue, 2021-11-30 at 09:20 -0500, Stephen Frost wrote: > Greetings, > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > Michael Paquier <michael@paquier.xyz> writes: > > > On Thu, Nov 25, 2021 at 06:19:03PM -0800, SATYANARAYANA NARLAPURAM wrote: > > > > If we are keeping it then why not make it better? > > > > > Well, non-exclusive backups are better by design in many aspects, so I > > > don't quite see the point in spending time on something that has more > > > limitations than what's already in place. > > > > IMO the main reason for keeping it is backwards compatibility for users > > who have a satisfactory backup arrangement using it. That same argument > > implies that we shouldn't change how it works (at least, not very much). > > There isn't a satisfactory backup approach using it specifically because > of this issue, hence why we should remove it to make it so users don't > run into this.
There is a satisfactory approach, as long as you are satisfied with manually restarting the server if it crashed during a backup.
I disagree that that’s a satisfactory approach. It certainly wasn’t intended or documented as part of the original feature and therefore to call it satisfactory strikes me quite strongly as revisionist history.
> I don't find the reasons brought up to continue to support exclusive > backup to be at all compelling and the lack of huge issues with the new > way restore works to make it abundently clear that we can, in fact, > remove exclusive backup in a major version change without the world > coming down.
I guess the lack of hue and cry was at least to a certain extent because the exclusive backup API was deprecated, but not removed.
These comments were in reference to the restore API, which was quite changed (new special files that have to be touched, removing of recovery.conf, options moved to postgresql.conf/.auto, etc). So, no.
