On Mon, Nov 26, 2018 at 6:44 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote:
> 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 :^) > Enjoy :) > > > 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. > Right, it turns out to actually be a hard problem. The old API pretended it wasn't, which wasn't really very helpful in the long run... 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. > Not if it's in the same physical location, no, I think that's really hard. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
