Em sáb., 29 de fev. de 2020 às 18:44, Tom Lane escreveu:
> "throw it away" sure looks like it means the entire hashtable, not just
> its tuple contents.
>
I don't know if I can comment clearly to help, but from my experience,
destroying and rebuilding the hashtable is a waste if possible, resetti
Andres Freund writes:
> On 2020-02-29 14:02:59 -0500, Tom Lane wrote:
>> TBH, I think that this tuple table API is seriously misdesigned;
>> it is confusing and very error-prone to have the callers need to
>> reset the tuple context separately from calling ResetTupleHashTable.
> Do you have an al
Hi,
On 2020-02-29 14:02:59 -0500, Tom Lane wrote:
> > 3. Additionally since the memory context used by the hash tables is
> > reset in buildSubPlanHash() if we start resetting hash tables we will
> > get a use after free bug.
>
> Nope, not right. The hash table metadata is now allocated in th
Andreas Karlsson writes:
> The code for resetting the hash tables of the SubPlanState node in
> buildSubPlanHash() looks like it can never run, and additionally it
> would be broken if it would ever run. This issue was introduced in
> commit 356687bd825e5ca7230d43c1bffe7a59ad2e77bd.
Right. Ju
Hi,
I looked again at one of the potential issues Ranier Vilela's static
analysis found and after looking more at it I still think this one is a
real bug. But my original patch was incorrect and introduced a use after
free bug.
The code for resetting the hash tables of the SubPlanState node
