On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost <sfr...@snowman.net> wrote: > 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.
Letting users taking unconsciously inconsistent backups is worse than potentially breaking scripts that were actually not working as Postgres would expect. So I am +1 for back-patching a lighter version of the proposed patch that makes the wait happen on purpose. >> > 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. Yes, let's avoid that. We are talking about a switch aimed at making backups potentially inconsistent. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
