Hi,,
On 2019-02-24 11:52:54 -0800, Christophe Pettus wrote:
> > On Feb 22, 2019, at 15:18, Stephen Frost <sfrost@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
