From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: subplan resets wrong hashtable |
Date: | 2020-02-10 04:53:08 |
Message-ID: | 20200210045308.GD1412@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 09, 2020 at 08:01:26PM -0800, Andres Freund wrote:
> 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?
Actually .. I can "theoretically" prove that there's no wrong results from that
patch...since in that file it has no effect, the tested variables being zeroed
few lines earlier:
@@ -499,51 +499,60 @@ buildSubPlanHash(SubPlanState *node, ExprContext *econtext)
* node->hashtable = NULL;
* node->hashnulls = NULL;
node->havehashrows = false;
node->havenullrows = false;
nbuckets = (long) Min(planstate->plan->plan_rows, (double) LONG_MAX);
if (nbuckets < 1)
nbuckets = 1;
- node->hashtable = BuildTupleHashTable(node->parent,
- node->descRight,
- ncols,
- node->keyColIdx,
- node->tab_eq_funcoids,
- node->tab_hash_funcs,
- nbuckets,
- 0,
- node->hashtablecxt,
- node->hashtempcxt,
- false);
*+ if (node->hashtable)
+ ResetTupleHashTable(node->hashtable);
+ else
+ node->hashtable = BuildTupleHashTableExt(node->parent,
...
*+ if (node->hashnulls)
+ ResetTupleHashTable(node->hashtable);
+ else
+ node->hashnulls = BuildTupleHashTableExt(node->parent,
+ node->descRight,
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2020-02-10 04:53:11 | Re: Is custom MemoryContext prohibited? |
Previous Message | Amit Langote | 2020-02-10 04:16:30 | Re: Identifying user-created objects |