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

From: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: 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 03:13:39
Message-ID: 4e93d707-cda6-8bc8-c1ba-6774f9926886@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10.07.2018 22:26, Fujii Masao wrote:
> On Tue, Jul 10, 2018 at 6:41 PM, Andrey V. Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>>
>>
>> On 10.07.2018 06:45, Andres Freund wrote:
>>>
>>> Hi,
>>>
>>> On 2018-07-10 06:41:32 +0500, Andrey V. Lepikhov wrote:
>>>>
>>>> This functionality is needed in practice when we have to determine a
>>>> recovery time of specific backup.
>>>
>>>
>>> What do you mean by "recovery time of specific backup"?
>>>
>>
>> recovery time - is a time point where backup of PostgreSQL database instance
>> was made.
>> Performing database recovery, we want to know what point in time the
>> restored database will correspond to.
>> This functionality refers to improving the usability of pg_basebackup and
>> pg_probackup utilities.
>
> Why don't you use a backup history file for that purpose?

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.

>
> Regards,
>

--
Andrey Lepikhov
Postgres Professional:
https://postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-07-13 03:34:43 Re: Cannot dump foreign key constraints on partitioned table
Previous Message Amit Kapila 2018-07-13 03:00:01 Re: Concurrency bug in UPDATE of partition-key