Re: [HACKERS] Reading timeline from pg_control on replication slave

2017-10-30 Thread Michael Paquier
On Mon, Oct 30, 2017 at 2:48 AM, Craig Ringer wrote: > (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). Yeah, I agree. My take on the matter is that we could just use the status data of the

Re: [HACKERS] Reading timeline from pg_control on replication slave

2017-10-29 Thread Craig Ringer
On 28 October 2017 at 06:09, Michael Paquier wrote: > On Fri, Oct 27, 2017 at 1:04 AM, Andrey Borodin 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

Re: [HACKERS] Reading timeline from pg_control on replication slave

2017-10-28 Thread Andrey Borodin
Hi, Michael! Thank you very much for these comments! > 28 окт. 2017 г., в 3:09, Michael Paquier > написал(а): > > ThisTimeLineID is not something you can rely on for standby backends > as it is not set during recovery. That's the reason behind > pg_walfile_name

Re: [HACKERS] Reading timeline from pg_control on replication slave

2017-10-27 Thread Michael Paquier
On Fri, Oct 27, 2017 at 1:04 AM, Andrey Borodin 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 >

[HACKERS] Reading timeline from pg_control on replication slave

2017-10-27 Thread Andrey Borodin
Hi, hackers! 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