Re: Expose last replayed timeline ID along with last replayed LSN - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Expose last replayed timeline ID along with last replayed LSN
Date
Msg-id CALj2ACUGVSBdjd1Cvv535PwK5mVG2VGPestKZsMXuaubmAomQA@mail.gmail.com
Whole thread Raw
In response to Re: Expose last replayed timeline ID along with last replayed LSN  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Next
From: Thomas Munro
Date:
Subject: Re: Remove fls(), use pg_bitutils.h facilities instead?