Fetching timeline during recovery

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Fetching timeline during recovery
Date: 2019-07-23 16:05:18
Message-ID: 20190723180518.635ac554@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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

Please, find in attachment a first trivial patch to support pg_walfile_name()
and pg_walfile_name_offset() on a standby.

Previous restriction on this functions seems related to ThisTimeLineID not
being safe on standby. This patch is fetching the timeline from
WalRcv->receivedTLI using GetWalRcvWriteRecPtr(). As far as I understand,
this is updated each time some data are flushed to the WAL.

As the SQL function pg_last_wal_receive_lsn() reads WalRcv->receivedUpto
which is flushed in the same time, any tool relying on these functions should be
quite fine. It will just have to parse the TL from the walfile name.

It doesn't seems perfectly sain though. I suspect a race condition in any SQL
statement that would try to get the LSN and the walfile name in the same time
if the timeline changes in the meantime. Ideally, a function should be able to
return both LSN and TL in the same time, with only one read from WalRcv. I'm not
sure if I should change the result from pg_last_wal_receive_lsn() or add a
brand new admin function. Any advice?

Last, I plan to produce an extension to support this on older release. Is
it something that could be integrated in official source tree during a minor
release or should I publish it on eg. pgxn?



Attachment Content-Type Size
0001-Support-pg_walfile_name-on-standby.patch text/x-patch 2.3 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-23 16:13:40 Re: Speed up transaction completion faster after many relations are accessed in a transaction
Previous Message Daniel Gustafsson 2019-07-23 15:30:35 Re: pg_upgrade version checking questions