Re: Updated backup APIs for non-exclusive backups - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Updated backup APIs for non-exclusive backups
Date
Msg-id 62e871d1f7908b74b14c6083ec9d1e0a56f28eb1.camel@cybertec.at
Whole thread Raw
In response to Re: Updated backup APIs for non-exclusive backups  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Updated backup APIs for non-exclusive backups
List pgsql-hackers
On Sun, 2018-11-25 at 22:01 +0100, Magnus Hagander wrote:
[about managing backups from pre- and post-file-system-backup scrips]
> I agree with your point that it's not an uncommon thing to need. If a good solution
> for it can be proposed that requires the exclusive backup interface, then I wouldn't
> be against un-deprecating that.  But that's going to require a lot more than just a
> documentation change, IMHO. What could perhaps be handled with a documentation change,
> however, is to document a good way for this type of setup to use the new interfaces.

Good point, and it puts the ball in my court :^)

> > I'm arguing on behalf of users that run a few databases, want a simple backup
> > solution and are ready to deal with the shortcomings.
> 
> Those that want a simple backup solution have one -- pg_basebackup.
> 
> The exclusive backup API is *not* simple. It is convenient, but it is not simple.
> 
> Actually having a simple API that worked with the pre/post backup scripts, that
> would be an improvement that we should definitely want!

Right; unfortunately it is not simple to come up with one that doesn't exhibit
the problems of the existing exclusive backup.

Perhaps it's theoretically impossible.  The goal is to disambiguate what a file
system backup sees in backup mode and what the startup process sees after a crash
in backup mode, and I can't see how that could be done.

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Handling of REGRESS_OPTS in MSVC for regression tests
Next
From: "myungkyu.lim"
Date:
Subject: RE: [Todo item] Add entry creation timestamp column topg_stat_replication