Re: Fetching timeline during recovery - Mailing list pgsql-hackers

From David Steele
Subject Re: Fetching timeline during recovery
Date
Msg-id de85df8c-36a7-14e0-7dc4-b4b4e1ba8ee3@pgmasters.net
Whole thread Raw
In response to Re: Fetching timeline during recovery  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Fetching timeline during recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
List pgsql-hackers
On 7/23/19 2:59 PM, Andrey Borodin wrote:
> 
>> 23 июля 2019 г., в 21:05, Jehan-Guillaume de Rorthais <jgdr@dalibo.com> написал(а):
>>
>> Fetching the timeline from a standby could be useful in various situation.
>> Either for backup tools [1] or failover tools during some kind of election
>> process.
> That backup tool is reading timeline from pg_control_checkpoint(). And formats WAL file name itself when necessary.

We do the same [1].

>> Please, find in attachment a first trivial patch to support pg_walfile_name()
>> and pg_walfile_name_offset() on a standby.
> 
> You just cannot format WAL file name for LSN when timeline changed. Because there are at least three WALs for that
point:previous, new and partial. However, reading TLI from checkpoint seems safe for backup purposes.
 
> The only reason for WAL-G to read that timeline is to mark backup invalid: if it's name is
base_00000001XXXXXXXXYY00000YYand timeline change happens, it should be named base_00000002XXXXXXXXYY00000YY
(consistencypoint is not on TLI 2), but WAL-G cannot rename backup during backup-push.
 

Naming considerations aside, I don't think that a timeline switch during
a standby backup is a good idea, mostly because it is (currently) not
tested.  We don't allow it in pgBackRest.

[1]
https://github.com/pgbackrest/pgbackrest/blob/release/2.15.1/lib/pgBackRest/Db.pm#L1008

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: [PATCH] Improve performance of NOTIFY over many databases (issueblocking on AccessExclusiveLock on object 0 of class 1262 of database 0)
Next
From: Andres Freund
Date:
Subject: Re: ANALYZE: ERROR: tuple already updated by self