I wrote:
> Right. So the incorrect ResetTupleHashTable call is unreachable
> (and a look at the code coverage report confirms that). The whole
> thing obviously is a bit hasty and unreviewed, but it doesn't have
> a live bug AFAICS ... or at least, if there's a bug, it's a memory
> leakage issue
Justin Pryzby writes:
> 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 "theoretic
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 wr
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?
No, I only noticed while reading code.
I tried briefly to
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
