Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost <sfr...@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
signature.asc
Description: Digital signature