On 2024/07/03 22:42, Robert Haas wrote:
On Wed, Jul 3, 2024 at 5:34 AM Fujii Masao <masao.fu...@oss.nttdata.com> wrote:
pg_wal_summary_contents() seems to miss the summary information with "limit"
that pg_walsummary reports. This appears to be a bug. The attached patch fixes this.
Oops. It looks like pg_wal_summary_contents() forgets to emit the
limit block when that's the only data for a particular relation fork.
And maybe you can make it emit the limit block multiple times if the
list of block numbers is long enough.
Thanks for the patch. I think you can commit and back-patch this, but
I don't think the commit message is quite right, because it's not like
this code just NEVER executes where it is located currently. Or am I
missing something?
Yes, so I updated the commit message. I borrowed your description and used it
in the message. Attached is the revised version of the patch.
If there are no objections, I will commit and backpatch it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 47bcd6d19e45b98b006fff1b495c8b65bd84c377 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fu...@postgresql.org>
Date: Wed, 3 Jul 2024 15:50:30 +0900
Subject: [PATCH v2] Fix bugs in pg_wal_summary_contents().
Previously, pg_wal_summary_contents() had two issues,
causing discrepancies between pg_wal_summary_contents()
and the pg_walsummary command on the same WAL summary file:
(1) It did not emit the limit block when that's the only data for
a particular relation fork.
(2) It emitted the same limit block multiple times if the list of
block numbers was long enough.
This commit fixes these bugs.
Backpatch to v17 where pg_wal_summary_contents() was added.
Author: Fujii Masao
Reviewed-by: Robert Haas
Discussion:
https://postgr.es/m/90980ee6-2da6-42f6-a7b0-b7bae62ae...@oss.nttdata.com
---
src/backend/backup/walsummaryfuncs.c | 34 ++++++++++++++--------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/backend/backup/walsummaryfuncs.c
b/src/backend/backup/walsummaryfuncs.c
index f082488b33..bb6a3a4a36 100644
--- a/src/backend/backup/walsummaryfuncs.c
+++ b/src/backend/backup/walsummaryfuncs.c
@@ -118,6 +118,23 @@ pg_wal_summary_contents(PG_FUNCTION_ARGS)
values[2] = ObjectIdGetDatum(rlocator.dbOid);
values[3] = Int16GetDatum((int16) forknum);
+ /*
+ * If the limit block is not InvalidBlockNumber, emit an extra
row
+ * with that block number and limit_block = true.
+ *
+ * There is no point in doing this when the limit_block is
+ * InvalidBlockNumber, because no block with that number or any
higher
+ * number can ever exist.
+ */
+ if (BlockNumberIsValid(limit_block))
+ {
+ values[4] = Int64GetDatum((int64) limit_block);
+ values[5] = BoolGetDatum(true);
+
+ tuple = heap_form_tuple(rsi->setDesc, values, nulls);
+ tuplestore_puttuple(rsi->setResult, tuple);
+ }
+
/* Loop over blocks within the current relation fork. */
while (1)
{
@@ -143,23 +160,6 @@ pg_wal_summary_contents(PG_FUNCTION_ARGS)
tuple = heap_form_tuple(rsi->setDesc, values,
nulls);
tuplestore_puttuple(rsi->setResult, tuple);
}
-
- /*
- * If the limit block is not InvalidBlockNumber, emit
an extra row
- * with that block number and limit_block = true.
- *
- * There is no point in doing this when the limit_block
is
- * InvalidBlockNumber, because no block with that
number or any
- * higher number can ever exist.
- */
- if (BlockNumberIsValid(limit_block))
- {
- values[4] = Int64GetDatum((int64) limit_block);
- values[5] = BoolGetDatum(true);
-
- tuple = heap_form_tuple(rsi->setDesc, values,
nulls);
- tuplestore_puttuple(rsi->setResult, tuple);
- }
}
}
--
2.45.1
