Hi,, 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. > > 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."
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. > Rather than deprecate the existing API, I'd rather see the documentation > updated to discuss the danger cases. You can't work around some of danger cases (crash in the wrong moment, your database doesn't come up properly), so I don't think docs really address the problem. Greetings, Andres Freund
