Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record
Date
Msg-id 20180713044014.GB23895@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: How to make partitioning scale better for larger numbers ofpartitions
Next
From: Thomas Munro
Date:
Subject: Re: Checkpoint not retrying failed fsync?