Fix handling of partitioned index in RelationGetNumberOfBlocksInFork()

petere · petere · commit 0d906b2c0b1f · 2021-08-26T08:59:32.000+02:00
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. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://www.postgresql.org/message-id/1d3a5fbe-f48b-8bea-80da-9a5c4244aef9@enterprisedb.com
diff --git 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);
