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.