Skip to content

Commit 99b6b70

Browse files
committed
Guard against table-AM-less relations in planner.
The executor will dump core if it's asked to execute a seqscan on a relation having no table AM, such as a view. While that shouldn't really happen, it's possible to get there via catalog corruption, such as a missing ON SELECT rule. It seems worth installing a defense against that. There are multiple plausible places for such a defense, but I picked the planner's get_relation_info(). Per discussion of bug #17646 from Kui Liu. Back-patch to v12 where the tableam APIs were introduced; in older versions you won't get a SIGSEGV, so it seems less pressing. Discussion: https://postgr.es/m/17646-70c93cfa40365776@postgresql.org
1 parent 3d7df87 commit 99b6b70

File tree

1 file changed

+16
-0
lines changed

1 file changed

+16
-0
lines changed

src/backend/optimizer/util/plancat.c

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -123,6 +123,22 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
123123
*/
124124
relation = table_open(relationObjectId, NoLock);
125125

126+
/*
127+
* Relations without a table AM can be used in a query only if they are of
128+
* special-cased relkinds. This check prevents us from crashing later if,
129+
* for example, a view's ON SELECT rule has gone missing. Note that
130+
* table_open() already rejected indexes and composite types.
131+
*/
132+
if (!relation->rd_tableam)
133+
{
134+
if (!(relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE ||
135+
relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
136+
ereport(ERROR,
137+
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
138+
errmsg("cannot open relation \"%s\"",
139+
RelationGetRelationName(relation))));
140+
}
141+
126142
/* Temporary and unlogged relations are inaccessible during recovery. */
127143
if (!RelationNeedsWAL(relation) && RecoveryInProgress())
128144
ereport(ERROR,

0 commit comments

Comments
 (0)