From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-hackers(at)postgresql(dot)org, n(dot)gluhov(at)postgrespro(dot)ru |
Subject: | Re: JSON constructors and window functions |
Date: | 2022-04-04 18:25:10 |
Message-ID: | f73bbf99-e17a-fdcc-fdfd-6a1096b6c12a@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/4/22 11:43, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 4/3/22 22:46, Andrew Dunstan wrote:
>>> On 4/3/22 20:11, Andres Freund wrote:
>>>> 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.
> But removing the hash entries would be just as much of a problem
> wouldn't it?
>
>
Yes, quite possibly. It looks from some experimentation as though,
unlike my naive preconception, it doesn't process each frame again from
the beginning, so losing the hash entries could indeed be an issue here.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-04-04 18:31:24 | Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? |
Previous Message | Andrew Dunstan | 2022-04-04 18:19:56 | Re: JSON constructors and window functions |