On 4/3/22 22:46, Andrew Dunstan wrote: > On 4/3/22 20:11, Andres Freund wrote: >> Hi, >> >> On 2022-04-03 18:56:39 -0400, Andrew Dunstan wrote: >>> Haven't found the issue yet :-( It happens on the second call for the >>> partition to json_check_unique_key(). >>> >>> Here's a more idiomatic and self-contained query that triggers the problem. >>> >>> >>> select json_objectagg('10' : ref_0.level2 with unique keys) >>> over (partition by ref_0.parent_no order by ref_0.level2) >>> from (values (1::int,1::int),(1,2),(2,1),(2,2)) as ref_0(parent_no,level2); >> The hash was created in a context that's already freed. >> > [...] >> >> I don't think you're allowed to free stuff in a finalfunc - we might reuse >> the >> transition state for further calls to the aggregate. >> > > Doh! Of course! I'll fix it in the morning. Thanks. > >
I've committed a fix for this. I didn't find something to clean out the hash table, so I just removed the 'hash_destroy' and left it at that. All the test I did came back with expected results. Maybe a hash_reset() is something worth having assuming it's possible? I note that simplehash has a reset function. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com