database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-08 11:42:09 +03:00
Code Activity

Fix slot type assumptions for nodeGather[Merge].

Browse Source 
The assumption made in 1a0586de36 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:
Andres Freund
2018-11-15 23:10:50 -08:00
parent f92cd73923
commit a387a3dff9
2 changed files with 31 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
src/backend/executor/nodeGatherMerge.c
View File

@ -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;