Skip to content

Commit de7e31a

Browse files
tglsfdcreshke
authored andcommitted
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 2b7d10d commit de7e31a

1 file changed

Lines changed: 16 additions & 0 deletions

File tree

src/backend/optimizer/util/plancat.c

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

139+
/*
140+
* Relations without a table AM can be used in a query only if they are of
141+
* special-cased relkinds. This check prevents us from crashing later if,
142+
* for example, a view's ON SELECT rule has gone missing. Note that
143+
* table_open() already rejected indexes and composite types.
144+
*/
145+
if (!relation->rd_tableam)
146+
{
147+
if (!(relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE ||
148+
relation->rd_rel->relkind == RELKIND_PARTITIONED_TABLE))
149+
ereport(ERROR,
150+
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
151+
errmsg("cannot open relation \"%s\"",
152+
RelationGetRelationName(relation))));
153+
}
154+
139155
/* Temporary and unlogged relations are inaccessible during recovery. */
140156
if (!RelationIsPermanent(relation) && RecoveryInProgress())
141157
ereport(ERROR,

0 commit comments

Comments
 (0)