Re: subplan resets wrong hashtable
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-02-10T04:01:26Z
Lists: pgsql-hackers
Hi, On 2020-02-09 21:25:47 -0600, Justin Pryzby wrote: > I believe the 2nd hunk should reset node->hashnulls, rather than reset > ->hashtable a 2nd time: > > @@ -505,7 +505,10 @@ buildSubPlanHash(SubPlanState *node, ExprContext *econtext) > if (nbuckets < 1) > nbuckets = 1; > > - node->hashtable = BuildTupleHashTable(node->parent, > + if (node->hashtable) > + ResetTupleHashTable(node->hashtable); > + else > + node->hashtable = BuildTupleHashTableExt(node->parent, > node->descRight, > ncols, > node->keyColIdx, > ... > > @@ -527,7 +531,11 @@ buildSubPlanHash(SubPlanState *node, ExprContext *econtext) > if (nbuckets < 1) > nbuckets = 1; > } > - node->hashnulls = BuildTupleHashTable(node->parent, > + > + if (node->hashnulls) > + ResetTupleHashTable(node->hashtable); > + else > + node->hashnulls = BuildTupleHashTableExt(node->parent, > node->descRight, > ncols, > node->keyColIdx, Ugh, that indeed looks wrong. Did you check whether it can actively cause wrong query results? If so, did you do theoretically, or got to a query returning wrong results? - Andres
Commits
-
Correctly re-use hash tables in buildSubPlanHash().
- 9eb6b652a46d 11.8 landed
- 96d783ae55b9 12.3 landed
- 58c47ccfff20 13.0 landed
-
Reset, not recreate, execGrouping.c style hashtables.
- 356687bd825e 12.0 cited