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

From: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 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-10 09:41:30
Message-ID: b20370b0-7a55-d3c5-d75e-db8090979ad5@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

>
>> This code developed in compatibility with WAL segments, which do not have a
>> timestamp in a XLOG_BACKUP_END record.
>
> I don't understand what "compatibility with WAL segments" could mean?
> And how are WAL segments related to "XLOG_BACKUP_END record", except as
> to how every WAL record is related? Are you thinking about the switch
> records?
>

In this case 'compatibility' means that patched postgres codes
(pg_basebackup, pg_probackup, pg_waldump etc) will correctly read WAL
segments which not contains a timestamp field in XLOG_BACKUP_END record.

> Greetings,
>
> Andres Freund
>

--
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 Peter Eisentraut 2018-07-10 10:01:00 Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Previous Message PG Doc comments form 2018-07-10 09:34:36 Typo in doc or wrong EXCLUDE implementation