Re: Updated backup APIs for non-exclusive backups

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Updated backup APIs for non-exclusive backups
Дата
Msg-id 56FA92D5.9060007@pgmasters.net
обсуждение исходный текст
Ответ на Re: Updated backup APIs for non-exclusive backups  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Updated backup APIs for non-exclusive backups  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On 3/22/16 12:31 PM, Magnus Hagander wrote:

> On Tue, Mar 22, 2016 at 5:27 PM, David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> wrote:>
>     > Adding the stop time column should be a simple addition and I don't see
>     > a problem with that. I think I misunderstood your original request on
>     > that. Because you are just talking about returning a timestamptz with
>     > the "right now" value for when you called pg_stop_backup()? Or to be
>     > specific, just before pg_Stop_backup *finished*. Or do you mean when
>     > pg_stop_backup() started?
>
>     What would be ideal is the minimum time that could be used for PITR.  In
>     an exclusive backup that's the time the end-of-backup record is written
>     to WAL.  In a non-exlusive backup I'm not quite sure how that works.

I guess I was hoping that you would know.  I fine with just getting the 
current timestamp as is currently done in do_pg_stop_backup().  It's not 
perfect but it will be pretty close.

I thought some more about putting STOP_WAL_LOCATION into the backup 
label and I think this is an important step.  Without that the recovery 
process needs to use pg_control to determine when the database has reach 
consistency and that will only work if pg_control was copied last.

In summary, I think the patch should be updated to include stop_time as 
a column and add STOP_WAL_LOCATION and STOP_TIME to backup_label.  The 
recovery process should read STOP_WAL_LOCATION from backup_label and use 
that to decide when the database has become consistent.

Thanks,
-- 
-David
david@pgmasters.net



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.
Следующее
От: David Steele
Дата:
Сообщение: Re: [PROPOSAL] Client Log Output Filtering