From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
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 15:43:31 |
Message-ID: | 1904842.1649087011@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2022-04-04 15:44:27 | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Previous Message | Nathan Bossart | 2022-04-04 15:42:18 | Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file |