Andres Freund wrote: > On 2019-02-24 11:52:54 -0800, Christophe Pettus wrote: > > > On Feb 22, 2019, at 15:18, Stephen Frost <sfr...@snowman.net> wrote: > > > Getting a solid and resiliant backup to work from a shell script is, imv > > > anyway (though I might have a bit of experience, having tried numerous > > > times myself and then realizing that it just isn't practical...), a > > > downright fool's errand.
Here is my run with the fool's cap on: https://github.com/cybertec-postgresql/safe-backup > > The reality, though, is that there are a lot of organizations who have > > invested time and effort into getting a backup strategy working using > > the existing APIs, and there will be quite a bit of pushback against > > the version in which the existing exclusive API is removed. > > > > Some of those will be able to move to non-exclusive backups easily; > > others won't. For the ones that can't move easily, the reaction will > > not be, "PostgreSQL version x has a safer backup API"; it will be > > "PostgreSQL version x broke our backups, so we're not upgrading to > > it." >From the reactions I see in the field, I'd agree. > I think it also depends on how we remove exclusive backups. If we do it > by adding a 'pg_run_hot_backup --conection-options -- shell_command_to_copy' > it ought to be pretty simple to fix scripts. Whereas right now, with the > requirement to manually have a postgres connection alive, which is > annoying to do from shell, is not the case. > > I think if we'd introduced a command like that, we'd have seen a higher > adoption of non-exclusive backups. I think that is a good idea and will do the trick for many people. It will be harder for those whose backup solution is driven by a central backup software that backs up the file system and just offers "pre-backup" and "post-backup" hooks. Yours, Laurenz Albe
