Re: [HACKERS] Reading timeline from pg_control on replication slave - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Reading timeline from pg_control on replication slave
Date
Msg-id CAMsr+YEEVuKAWW_b2AsWWUuEYRoOXSyd0K9EUtRJLkjenrd1ug@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Reading timeline from pg_control on replication slave  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Reading timeline from pg_control on replication slave
List pgsql-hackers
On 28 October 2017 at 06:09, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Fri, Oct 27, 2017 at 1:04 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>> I'm working on backups from replication salve in WAL-G [0]
>> Backups used to use result of pg_walfile_name(pg_start_backup(...)). Call to pg_start_backup() works nice, but
"pg_walfile_name()cannot be executed during recovery."
 
>> This function has LSN as argument and reads TimeLineId from global state.
>> So I made a function[1] that, if on replica, reads timeline from pg_control file and formats WAL file name as is it
wasproduces by pg_wal_filename(lsn).
 
>
> ThisTimeLineID is not something you can rely on for standby backends
> as it is not set during recovery.

That's not much of a concern really, you just have to ensure you call
GetXLogReplayRecPtr and set ThisTimeLineID.

(I'd quite like ThisTimeLineID to go away as a global. It's messy and
confusing, and I'd much rather it be fetched when needed).

However, that doesn't negate the rest of the issues you raised.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Parallel safety for extern params
Next
From: Etsuro Fujita
Date:
Subject: [HACKERS] Comment typo