Thread: Expose last replayed timeline ID along with last replayed LSN

Expose last replayed timeline ID along with last replayed LSN

From
Bharath Rupireddy
Date:
Hi,

At times it's useful to know the last replayed WAL record's timeline
ID (especially on the standbys that are lagging in applying WAL while
failing over - for reporting, logging and debugging purposes). AFICS,
there's no function that exposes the last replayed TLI. We can either
change the existing pg_last_wal_replay_lsn() to report TLI along with
the LSN which might break the compatibility or introduce a new
function pg_last_wal_replay_info() that emits both LSN and TLI. I'm
fine with either of the approaches, but for now, I'm attaching a WIP
patch that adds a new function pg_last_wal_replay_info().

Thoughts?

Regards,
Bharath Rupireddy.

Attachment

Re: Expose last replayed timeline ID along with last replayed LSN

From
Kyotaro Horiguchi
Date:
At Tue, 19 Jul 2022 14:28:40 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> Hi,
> 
> At times it's useful to know the last replayed WAL record's timeline
> ID (especially on the standbys that are lagging in applying WAL while
> failing over - for reporting, logging and debugging purposes). AFICS,
> there's no function that exposes the last replayed TLI. We can either
> change the existing pg_last_wal_replay_lsn() to report TLI along with
> the LSN which might break the compatibility or introduce a new
> function pg_last_wal_replay_info() that emits both LSN and TLI. I'm
> fine with either of the approaches, but for now, I'm attaching a WIP
> patch that adds a new function pg_last_wal_replay_info().
> 
> Thoughts?

There was a more comprehensive discussion [1], which went nowhere..

[1] https://www.postgresql.org/message-id/20191211052002.GK72921%40paquier.xyz

regadrs.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



Re: Expose last replayed timeline ID along with last replayed LSN

From
Bharath Rupireddy
Date:
On Wed, Jul 20, 2022 at 7:06 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Tue, 19 Jul 2022 14:28:40 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
> > Hi,
> >
> > At times it's useful to know the last replayed WAL record's timeline
> > ID (especially on the standbys that are lagging in applying WAL while
> > failing over - for reporting, logging and debugging purposes). AFICS,
> > there's no function that exposes the last replayed TLI. We can either
> > change the existing pg_last_wal_replay_lsn() to report TLI along with
> > the LSN which might break the compatibility or introduce a new
> > function pg_last_wal_replay_info() that emits both LSN and TLI. I'm
> > fine with either of the approaches, but for now, I'm attaching a WIP
> > patch that adds a new function pg_last_wal_replay_info().
> >
> > Thoughts?
>
> There was a more comprehensive discussion [1], which went nowhere..
>
> [1] https://www.postgresql.org/message-id/20191211052002.GK72921%40paquier.xyz

Thanks Kyotaro-san for pointing at that thread. Infact, I did think
about having a new set of info functions pg_current_wal_info,
pg_current_wal_insert_info, pg_current_wal_flush_info,
pg_last_wal_receive_info, pg_last_wal_replay_info - IMO, these APIs
are the ones that we would want to keep in the code going forward.
Although they introduce some more code momentarily, eventually, it
makes sense to delete pg_current_wal_lsn, pg_current_wal_insert_lsn,
pg_current_wal_flush_lsn, pg_last_wal_receive_lsn,
pg_last_wal_replay_lsn, perhaps in the future versions of PG.

Thoughts?

Regards,
Bharath Rupireddy.