1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00

Don't shut down Gather[Merge] early under Limit.

Revert part of commit 19df1702f5.

Early shutdown was added by that commit so that we could collect
statistics from workers, but unfortunately, it interacted badly with
rescans.  The problem is that we ended up destroying the parallel context
which is required for rescans.  This leads to rescans of a Limit node over
a Gather node to produce unpredictable results as it tries to access
destroyed parallel context.  By reverting the early shutdown code, we
might lose statistics in some cases of Limit over Gather [Merge], but that
will require further study to fix.

Reported-by: Jerry Sievers
Diagnosed-by: Thomas Munro
Author: Amit Kapila, testcase by Vignesh C
Backpatch-through: 9.6
Discussion: https://postgr.es/m/87ims2amh6.fsf@jsievers.enova.com
This commit is contained in:
Amit Kapila
2019-11-18 14:17:41 +05:30
parent a24a4167aa
commit 1cc3a90c75
3 changed files with 67 additions and 10 deletions

View File

@ -129,19 +129,17 @@ ExecLimit(PlanState *pstate)
* we are at the end of the window, return NULL without
* advancing the subplan or the position variable; but change
* the state machine state to record having done so.
*
* Once at the end, ideally, we can shut down parallel
* resources but that would destroy the parallel context which
* would be required for rescans. To do that, we need to find
* a way to pass down more information about whether rescans
* are possible.
*/
if (!node->noCount &&
node->position - node->offset >= node->count)
{
node->lstate = LIMIT_WINDOWEND;
/*
* If we know we won't need to back up, we can release
* resources at this point.
*/
if (!(node->ps.state->es_top_eflags & EXEC_FLAG_BACKWARD))
(void) ExecShutdownNode(outerPlan);
return NULL;
}