Re: Fetching timeline during recovery

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fetching timeline during recovery
Date: 2019-07-26 16:22:25
Message-ID: 20190726182225.6dc23664@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, 26 Jul 2019 10:02:58 +0200
Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> wrote:

> On Fri, 26 Jul 2019 16:49:53 +0900 (Tokyo Standard Time)
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > We have an LSN reporting function each for several objectives.
> >
> > pg_current_wal_lsn
> > pg_current_wal_insert_lsn
> > pg_current_wal_flush_lsn
> > pg_last_wal_receive_lsn
> > pg_last_wal_replay_lsn
> Yes. In fact, my current implementation might be split as:
> pg_current_wal_tl: returns TL on a production cluster
> pg_last_wal_received_tl: returns last received TL on a standby
> If useful, I could add pg_last_wal_replayed_tl. I don't think *insert_tl and
> *flush_tl would be useful as a cluster in production is not supposed to
> change its timeline during its lifetime.
> > But, I'm not sure just adding further pg_last_*_timeline() to
> > this list is a good thing..
> I think this is a much better idea than mixing different case (production and
> standby) in the same function as I did. Moreover, it's much more coherent with
> other existing functions.

Please, find in attachment a new version of the patch. It now creates two new



Attachment Content-Type Size
0001-v2-Add-functions-to-get-timeline.patch text/x-patch 4.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2019-07-26 16:26:28 Re: POC: Cleaning up orphaned files using undo logs
Previous Message Ryan Lambert 2019-07-26 16:20:34 Re: Built-in connection pooler