While analyzing this again, I think I found an existing mistake. The
handling of RELKIND_PARTITIONED_INDEX in
RelationGetNumberOfBlocksInFork() seems to be misplaced. See attached
patch.
From 652d10eaf00aafb91c6f60149b04be90a33e5acb Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pe...@eisentraut.org>
Date: Tue, 24 Aug 2021 11:56:08 +0200
Subject: [PATCH] Fix handling of partitioned index in
RelationGetNumberOfBlocksInFork()
Since a partitioned index doesn't have storage, getting the number of
blocks from it will not give sensible results. Existing callers
already check that they don't call it that way, so there doesn't
appear to be a live problem. But for correctness, handle
RELKIND_PARTITIONED_INDEX together with the other non-storage
relkinds.
---
src/backend/storage/buffer/bufmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/storage/buffer/bufmgr.c
b/src/backend/storage/buffer/bufmgr.c
index 3b485de067..bc1753ae91 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -2929,7 +2929,6 @@ RelationGetNumberOfBlocksInFork(Relation relation,
ForkNumber forkNum)
{
case RELKIND_SEQUENCE:
case RELKIND_INDEX:
- case RELKIND_PARTITIONED_INDEX:
return smgrnblocks(RelationGetSmgr(relation), forkNum);
case RELKIND_RELATION:
@@ -2951,6 +2950,7 @@ RelationGetNumberOfBlocksInFork(Relation relation,
ForkNumber forkNum)
case RELKIND_VIEW:
case RELKIND_COMPOSITE_TYPE:
case RELKIND_FOREIGN_TABLE:
+ case RELKIND_PARTITIONED_INDEX:
case RELKIND_PARTITIONED_TABLE:
default:
Assert(false);
--
2.33.0
