Обсуждение: Expose last replayed timeline ID along with last replayed LSN

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.

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

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.