Re: pg_stop_backup(wait_for_archive := true) on standby server
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>, David Steele <david@pgmasters.net>, Masahiko Sawada <sawada.mshk@gmail.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, Noah Misch <noah@leadboat.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-07-24T19:43:15Z
Lists: pgsql-hackers
On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost <sfrost@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
Commits
-
Make pg_stop_backup's wait_for_archive flag work on standbys.
- 52f8a59dd953 10.0 landed
-
Implement backup API functions for non-exclusive backups
- 7117685461af 9.6.0 cited