From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reading timeline from pg_control on replication slave |
Date: | 2017-10-30 02:48:11 |
Message-ID: | CAMsr+YEEVuKAWW_b2AsWWUuEYRoOXSyd0K9EUtRJLkjenrd1ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 October 2017 at 06:09, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Oct 27, 2017 at 1:04 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)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 was produces 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2017-10-30 02:49:39 | Comment typo |
Previous Message | Amit Kapila | 2017-10-30 02:44:21 | Re: Parallel safety for extern params |