mirror of
				https://github.com/postgres/postgres.git
				synced 2025-11-04 00:02:52 -05:00 
			
		
		
		
	Fix slot type assumptions for nodeGather[Merge].
The assumption made in 1a0586de3657c was wrong, as evidenced by buildfarm failure on locust, which runs with force_parallel_mode=regress. The tuples accessed in either nodes are in the outer slot, and we can't trivially rely on the slot type being known because the leader might execute the subsidiary node directly, or via the tuple queue on a worker. In the latter case the tuple will always be a heaptuple slot, but in the former, it'll be whatever the subsidiary node returns.
This commit is contained in:
		
							parent
							
								
									f92cd73923
								
							
						
					
					
						commit
						a387a3dff9
					
				@ -91,10 +91,14 @@ ExecInitGather(Gather *node, EState *estate, int eflags)
 | 
			
		||||
	outerPlanState(gatherstate) = ExecInitNode(outerNode, estate, eflags);
 | 
			
		||||
	tupDesc = ExecGetResultType(outerPlanState(gatherstate));
 | 
			
		||||
 | 
			
		||||
	/* this node uses tuples from the tuple queue as scan slot */
 | 
			
		||||
	gatherstate->ps.scanops = &TTSOpsHeapTuple;
 | 
			
		||||
	gatherstate->ps.scanopsfixed = true;
 | 
			
		||||
	gatherstate->ps.scanopsset = true;
 | 
			
		||||
	/*
 | 
			
		||||
	 * Leader may access ExecProcNode result directly (if
 | 
			
		||||
	 * need_to_scan_locally), or from workers via tuple queue.  So we can't
 | 
			
		||||
	 * trivially rely on the slot type being fixed for expressions evaluated
 | 
			
		||||
	 * within this node.
 | 
			
		||||
	 */
 | 
			
		||||
	gatherstate->ps.outeropsset = true;
 | 
			
		||||
	gatherstate->ps.outeropsfixed = false;
 | 
			
		||||
 | 
			
		||||
	/*
 | 
			
		||||
	 * Initialize result type and projection.
 | 
			
		||||
@ -102,6 +106,16 @@ ExecInitGather(Gather *node, EState *estate, int eflags)
 | 
			
		||||
	ExecInitResultTypeTL(&gatherstate->ps);
 | 
			
		||||
	ExecConditionalAssignProjectionInfo(&gatherstate->ps, tupDesc, OUTER_VAR);
 | 
			
		||||
 | 
			
		||||
	/*
 | 
			
		||||
	 * Without projections result slot type is not trivially known, see
 | 
			
		||||
	 * comment above.
 | 
			
		||||
	 */
 | 
			
		||||
	if (gatherstate->ps.ps_ProjInfo == NULL)
 | 
			
		||||
	{
 | 
			
		||||
		gatherstate->ps.resultopsset = true;
 | 
			
		||||
		gatherstate->ps.resultopsfixed = false;
 | 
			
		||||
	}
 | 
			
		||||
 | 
			
		||||
	/*
 | 
			
		||||
	 * Initialize funnel slot to same tuple descriptor as outer plan.
 | 
			
		||||
	 */
 | 
			
		||||
 | 
			
		||||
@ -109,6 +109,15 @@ ExecInitGatherMerge(GatherMerge *node, EState *estate, int eflags)
 | 
			
		||||
	outerNode = outerPlan(node);
 | 
			
		||||
	outerPlanState(gm_state) = ExecInitNode(outerNode, estate, eflags);
 | 
			
		||||
 | 
			
		||||
	/*
 | 
			
		||||
	 * Leader may access ExecProcNode result directly (if
 | 
			
		||||
	 * need_to_scan_locally), or from workers via tuple queue.  So we can't
 | 
			
		||||
	 * trivially rely on the slot type being fixed for expressions evaluated
 | 
			
		||||
	 * within this node.
 | 
			
		||||
	 */
 | 
			
		||||
	gm_state->ps.outeropsset = true;
 | 
			
		||||
	gm_state->ps.outeropsfixed = false;
 | 
			
		||||
 | 
			
		||||
	/*
 | 
			
		||||
	 * Store the tuple descriptor into gather merge state, so we can use it
 | 
			
		||||
	 * while initializing the gather merge slots.
 | 
			
		||||
@ -122,7 +131,10 @@ ExecInitGatherMerge(GatherMerge *node, EState *estate, int eflags)
 | 
			
		||||
	ExecInitResultTypeTL(&gm_state->ps);
 | 
			
		||||
	ExecConditionalAssignProjectionInfo(&gm_state->ps, tupDesc, OUTER_VAR);
 | 
			
		||||
 | 
			
		||||
	/* leader accesses ExecProcNode result directly, others go through tuple queue */
 | 
			
		||||
	/*
 | 
			
		||||
	 * Without projections result slot type is not trivially known, see
 | 
			
		||||
	 * comment above.
 | 
			
		||||
	 */
 | 
			
		||||
	if (gm_state->ps.ps_ProjInfo == NULL)
 | 
			
		||||
	{
 | 
			
		||||
		gm_state->ps.resultopsset = true;
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user