|From:||Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Subject:||Re: Fetching timeline during recovery|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, 24 Jul 2019 14:33:27 +0200
Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> wrote:
> On Wed, 24 Jul 2019 09:49:05 +0900
> Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Tue, Jul 23, 2019 at 06:05:18PM +0200, Jehan-Guillaume de Rorthais
> > wrote:
> > I think that there are arguments for being more flexible with it, and
> > perhaps have a system-level view to be able to look at some of its fields.
> Great idea. I'll give it a try to keep the discussion on.
After some thinking, I did not find enough data to expose to justify the
creation a system-level view. As I just need the current timeline I
wrote "pg_current_timeline()". Please, find the patch in attachment.
The current behavior is quite simple:
* if the cluster is in production, return ThisTimeLineID
* else return walrcv->receivedTLI (using GetWalRcvWriteRecPtr)
This is really naive implementation. We should probably add some code around
the startup process to gather and share general recovery stats. This would
allow to fetch eg. the current recovery method, latest xlog file name restored
from archives or streaming, its timeline, etc.
|Next Message||Masahiko Sawada||2019-07-25 17:54:04||Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)|
|Previous Message||Bruce Momjian||2019-07-25 17:23:40||Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)|