mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-29 22:49:41 +03:00 
			
		
		
		
	Fix incorrect logic for caching ResultRelInfos for triggers
When dealing with ResultRelInfos for partitions, there are cases where there are mixed requirements for the ri_RootResultRelInfo. There are cases when the partition itself requires a NULL ri_RootResultRelInfo and in the same query, the same partition may require a ResultRelInfo with its parent set in ri_RootResultRelInfo. This could cause the column mapping between the partitioned table and the partition not to be done which could result in crashes if the column attnums didn't match exactly. The fix is simple. We now check that the ri_RootResultRelInfo matches what the caller passed to ExecGetTriggerResultRel() and only return a cached ResultRelInfo when the ri_RootResultRelInfo matches what the caller wants, otherwise we'll make a new one. Author: David Rowley <dgrowleyml@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Reported-by: Dmitry Fomin <fomin.list@gmail.com> Discussion: https://postgr.es/m/7DCE78D7-0520-4207-822B-92F60AEA14B4@gmail.com Backpatch-through: 15
This commit is contained in:
		| @@ -1343,10 +1343,9 @@ InitResultRelInfo(ResultRelInfo *resultRelInfo, | ||||
|  *		Get a ResultRelInfo for a trigger target relation. | ||||
|  * | ||||
|  * Most of the time, triggers are fired on one of the result relations of the | ||||
|  * query, and so we can just return a member of the es_result_relations array, | ||||
|  * or the es_tuple_routing_result_relations list (if any). (Note: in self-join | ||||
|  * situations there might be multiple members with the same OID; if so it | ||||
|  * doesn't matter which one we pick.) | ||||
|  * query, and so we can just return a suitable one we already made and stored | ||||
|  * in the es_opened_result_relations or es_tuple_routing_result_relations | ||||
|  * Lists. | ||||
|  * | ||||
|  * However, it is sometimes necessary to fire triggers on other relations; | ||||
|  * this happens mainly when an RI update trigger queues additional triggers | ||||
| @@ -1366,11 +1365,20 @@ ExecGetTriggerResultRel(EState *estate, Oid relid, | ||||
| 	Relation	rel; | ||||
| 	MemoryContext oldcontext; | ||||
|  | ||||
| 	/* | ||||
| 	 * Before creating a new ResultRelInfo, check if we've already made and | ||||
| 	 * cached one for this relation.  We must ensure that the given | ||||
| 	 * 'rootRelInfo' matches the one stored in the cached ResultRelInfo as | ||||
| 	 * trigger handling for partitions can result in mixed requirements for | ||||
| 	 * what ri_RootResultRelInfo is set to. | ||||
| 	 */ | ||||
|  | ||||
| 	/* Search through the query result relations */ | ||||
| 	foreach(l, estate->es_opened_result_relations) | ||||
| 	{ | ||||
| 		rInfo = lfirst(l); | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid) | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid && | ||||
| 			rInfo->ri_RootResultRelInfo == rootRelInfo) | ||||
| 			return rInfo; | ||||
| 	} | ||||
|  | ||||
| @@ -1381,7 +1389,8 @@ ExecGetTriggerResultRel(EState *estate, Oid relid, | ||||
| 	foreach(l, estate->es_tuple_routing_result_relations) | ||||
| 	{ | ||||
| 		rInfo = (ResultRelInfo *) lfirst(l); | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid) | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid && | ||||
| 			rInfo->ri_RootResultRelInfo == rootRelInfo) | ||||
| 			return rInfo; | ||||
| 	} | ||||
|  | ||||
| @@ -1389,7 +1398,8 @@ ExecGetTriggerResultRel(EState *estate, Oid relid, | ||||
| 	foreach(l, estate->es_trig_target_relations) | ||||
| 	{ | ||||
| 		rInfo = (ResultRelInfo *) lfirst(l); | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid) | ||||
| 		if (RelationGetRelid(rInfo->ri_RelationDesc) == relid && | ||||
| 			rInfo->ri_RootResultRelInfo == rootRelInfo) | ||||
| 			return rInfo; | ||||
| 	} | ||||
| 	/* Nope, so we need a new one */ | ||||
|   | ||||
		Reference in New Issue
	
	Block a user