Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server |
Дата | |
Msg-id | CAB7nPqQTNixBv2nocB8DCbSw+w5WynkvUenfk0G_=ns3O9ntVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standbyserver (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server
|
Список | 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
В списке pgsql-hackers по дате отправления: