Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record
Дата
Msg-id 20180713044014.GB23895@paquier.xyz
обсуждение исходный текст
Ответ на Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Список pgsql-hackers
On Fri, Jul 13, 2018 at 08:13:39AM +0500, Andrey V. Lepikhov wrote:
> Timestamp in a backup history file not correspond to any WAL record and
> can't be bind with a time of backup exactly.
> In my opinion, keeping timestamp in XLOG_BACKUP_END is more reliable, safe
> and easy way for recovering a database to a specific time.

Like Andres and Fujii-san, I don't really see the point of complicating
the code for that.  If your goal is to stop WAL replay once consistency
has been reached, then just use recovery_target = 'immediate' if you
fetch the data from a WAL archive and that there are still segments
after the consistency point.  Or just use a self-contained backup which
has all the WAL it needs without restore_command.

If your goal is to make sure that the timestamp set in recovery.conf is
not older than the moment the backup has ended, then the backup history
file has what you are looking for.  In short, in any case there is no
point in duplicating data which already exists.  You can as well use
recovery_target_lsn to point exactly at the time a backup has ended as
returned by pg_stop_backup, and this even saves maths with timestamps.
--
Michael

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: How to make partitioning scale better for larger numbers ofpartitions
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Checkpoint not retrying failed fsync?