Expose last replayed timeline ID along with last replayed LSN

Started by Bharath Rupireddyover 3 years ago3 messages
#1Bharath Rupireddy
bharath.rupireddyforpostgres@gmail.com
1 attachment(s)

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.

Attachments:

v1-0001-Add-new-function-pg_last_wal_replay_info.patchapplication/octet-stream; name=v1-0001-Add-new-function-pg_last_wal_replay_info.patchDownload
From 9402f8868d64f12cf6cd7b2fea5aeec146a5c54d Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Tue, 19 Jul 2022 08:52:19 +0000
Subject: [PATCH v1] Add new function pg_last_wal_replay_info()

---
 src/backend/access/transam/xlogfuncs.c | 36 ++++++++++++++++++++++++++
 src/include/catalog/pg_proc.dat        |  5 ++++
 2 files changed, 41 insertions(+)

diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/access/transam/xlogfuncs.c
index 61e0f4a29c..db07dbb6a8 100644
--- a/src/backend/access/transam/xlogfuncs.c
+++ b/src/backend/access/transam/xlogfuncs.c
@@ -313,6 +313,42 @@ pg_last_wal_replay_lsn(PG_FUNCTION_ARGS)
 	PG_RETURN_LSN(recptr);
 }
 
+#define PG_LAST_WAL_REPLAY_INFO_COLS 2
+Datum
+pg_last_wal_replay_info(PG_FUNCTION_ARGS)
+{
+	HeapTuple	tuple;
+	TupleDesc	tupleDesc;
+	Datum		values[PG_LAST_WAL_REPLAY_INFO_COLS] = {0};
+	bool		nulls[PG_LAST_WAL_REPLAY_INFO_COLS] = {0};
+	Datum		result;
+	XLogRecPtr	recptr;
+	TimeLineID	tli;
+
+	recptr = GetXLogReplayRecPtr(&tli);
+
+	/*
+	 * Build a tuple descriptor for our result type
+	 */
+	if (get_call_result_type(fcinfo, NULL, &tupleDesc) != TYPEFUNC_COMPOSITE)
+		elog(ERROR, "return type must be a row type");
+
+	if (recptr == 0)
+		PG_RETURN_NULL();
+
+	values[0] = Int32GetDatum(recptr);
+	values[1] = Int64GetDatum(tli);
+
+	/*
+	 * Build and return the tuple
+	 */
+	tuple = heap_form_tuple(tupleDesc, values, nulls);
+	result = HeapTupleGetDatum(tuple);
+
+	PG_RETURN_DATUM(result);
+}
+#undef PG_LAST_WAL_REPLAY_INFO_COLS
+
 /*
  * Compute an xlog file name and decimal byte offset given a WAL location,
  * such as is returned by pg_backup_stop() or pg_switch_wal().
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 2e41f4d9e8..71ce3720ca 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -6356,6 +6356,11 @@
   proname => 'pg_last_xact_replay_timestamp', provolatile => 'v',
   prorettype => 'timestamptz', proargtypes => '',
   prosrc => 'pg_last_xact_replay_timestamp' },
+{ oid => '9319', descr => 'get last replayed wal info such as lsn, timeline id',
+  proname => 'pg_last_wal_replay_info', prorows => '1',
+  provolatile => 'v', prorettype => 'record', proargtypes => '',
+  proallargtypes => '{pg_lsn,int4}', proargmodes => '{o,o}',
+  proargnames => '{lsn, timeline_id}', prosrc => 'pg_last_wal_replay_info' },
 
 { oid => '3071', descr => 'pause wal replay',
   proname => 'pg_wal_replay_pause', provolatile => 'v', prorettype => 'void',
-- 
2.25.1

#2Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Bharath Rupireddy (#1)
Re: Expose last replayed timeline ID along with last replayed LSN

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]/messages/by-id/20191211052002.GK72921@paquier.xyz, which went nowhere..

[1]: /messages/by-id/20191211052002.GK72921@paquier.xyz

regadrs.

--
Kyotaro Horiguchi
NTT Open Source Software Center

#3Bharath Rupireddy
bharath.rupireddyforpostgres@gmail.com
In reply to: Kyotaro Horiguchi (#2)
Re: Expose last replayed timeline ID along with last replayed LSN

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] /messages/by-id/20191211052002.GK72921@paquier.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.