Robert,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > Those backup scripts might very well be, today, producing invalid
> > backups though, which would be much less good..
>
> True. However, I suspect that depends on what procedure is actually
> being followed. If *everyone* who is using this is getting corrupt
> backups, then of course changing the behavior is a no-brainer. But if
> *some* people are getting correct backups and *some* people are
> getting incorrect backups, depending on procedure, then I think
> changing it is unwise. We should optimize for the case of a user who
> is currently doing something smart, not one who is doing something
> dumb.
I'm not sure that we can call "writing code that depends on what the
docs say" dumb, unfortunately, and if even one person is getting an
invalid backup while following what the docs say then that's a strong
case to do *something*. Of course, we also don't want to break the
scripts of people who are doing things correctly, but I'm trying to
figure out exactly how this change would break such scripts.
What the change would do is make the pg_stop_backup() caller block until
the last WAL is archvied, and perhaps that ends up taking hours, and
then the connection is dropped for whatever reason and the backup fails
where it otherwise.... what? wouldn't have been valid anyway at that
point, since it's not valid until the last WAL is actually archived.
Perhaps eventually it would be archived and the caller was planning for
that and everything is fine, but, well, that feels like an awful lot of
wishful thinking.
And that's assuming that the script author made sure to write additional
code that didn't mark the backup as valid until the ending WAL segment
from pg_stop_backup() was confirmed to have been archived.
Last, but perhaps not least, this is at least just an issue going back
to where pg_start/stop_backup was allowed on replicas, which is only 9.6
and therefore it's been out less than a year and anyone's script which
might break due to this would at least be relatively new code.
> > I'd hate to have to do it, but we could technically add a GUC to address
> > this in the back-branches, no? I'm not sure that's really worthwhile
> > though..
>
> That would be mighty ugly.
Oh, absolutely agreed.
Thanks!
Stephen