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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "g(dot)smolkin(at)postgrespro(dot)ru" <g(dot)smolkin(at)postgrespro(dot)ru>
Subject: Re: [PATCH] Timestamp for a XLOG_BACKUP_END WAL-record
Date: 2018-07-13 04:40:14
Message-ID: 20180713044014.GB23895@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-07-13 04:44:19 Re: Checkpoint not retrying failed fsync?
Previous Message Amit Langote 2018-07-13 04:34:47 Re: How to make partitioning scale better for larger numbers of partitions