From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Jayesh Dehankar <jayesh(dot)dp(at)zohocorp(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "zlabs-cstore(at)zohocorp(dot)com" <zlabs-cstore(at)zohocorp(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [Bug] Heap Use After Free in Window Aggregate Execution |
Date: | 2024-12-09 01:28:26 |
Message-ID: | CAApHDvr=DTKWANVWjGh9OoygiCCFw_ORRyE4Aj44xS_gKDMHLQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, 14 Nov 2024 at 04:31, Jayesh Dehankar <jayesh(dot)dp(at)zohocorp(dot)com> wrote:
> We have discovered a bug in PostgreSQL v16.3 related to a top-level window aggregate with a partition-by clause. The issue occurs when the run condition fails, causing the window aggregate status to change from WINDOWAGG_RUN to WINDOWAGG_PASSTHROUGH_STRICT mode. The bug is present in the latest STABLE branch.
> 2) Execute below SQL queries:
> create table issue(a int, f text);
> insert into issue values (1, 'aa'), (1, 'bb');
> select * from ( select row_number() over (partition by a) as first, lead(f) over (partition by a) as third from issue) emp where first < 1;
Thank you for the detailed report and reproducer.
I've pushed a fix for this issue. It should be available in the 16.7
release around mid-Feb 2025.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tender Wang | 2024-12-09 02:56:50 | Re: BUG #18741: Detaching a partition referencing a partitioned table fails with a trigger-related error |
Previous Message | Tom Lane | 2024-12-08 22:55:12 | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-12-09 01:48:42 | Re: Missing LWLock protection in pgstat_reset_replslot() |
Previous Message | Noah Misch | 2024-12-09 01:25:41 | Re: Proper object locking for GRANT/REVOKE |