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.

Reviewed-by: Michael Paquier 
Reviewed-by: Alvaro Herrera 
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
index 3b485de067f1b072e6c7ee1d28cc946afba70124..bc1753ae916068cdf9e9d690a0f57b22b6c0b63d 100644 (file)
--- 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);