Re: Updated backup APIs for non-exclusive backups

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Updated backup APIs for non-exclusive backups
Дата
Msg-id CABUevEzgehfCGnfxTpCa85VJ+05sxTciMc9iHDqhVu4u9_njZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Updated backup APIs for non-exclusive backups  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers


On Wed, Mar 30, 2016 at 10:09 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Mar 29, 2016 at 11:39 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Tue, Mar 29, 2016 at 6:40 PM, Magnus Hagander <magnus@hagander.net> wrote:
So - I can definitely see the argument for returning the stop wal *location*. But I'm still not sure what the definition of the time would be? We can't return it before we know what it means...


I had a chat with Heikki, and here's another suggestion:

1. We don't touch the current exclusive backups at all, as previously discussed, other than deprecating their use. For backwards compat.

2. For new backups, we return the contents of pg_control as a bytea from pg_stop_backup(). We tell backup programs they are supposed to write this out as pg_control.backup, *not* as pg_control.

3a. On recovery, if it's an exlcusive backup, we do as we did before.

3b. on recovery, in non-exclusive backups (determined from backup_label), we check that pg_control.backup exists *and* that pg_control does *not* exist.

Currently pg_control has been read before backup_label file, so as per this proposal do you want to change that?  If yes, I think that will make this patch more invasive with respect to handling of failure modes.  Also as David points out, I also feel that it will raise the bar for usage of this API.

Yes, we'd have to change that. I don't think it's going to be much more invasive than reading part of it from pg_control and part of it from backup_label, as suggested by David. It would be a bit more complicated than what we have today - but it would move complication from user scripts (that are likely to get it wrong) to a central place in the backend (where we can be more certain that it's at least less wrong). 


--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Updated backup APIs for non-exclusive backups
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.