From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bug in nbtree SAOP scans with non-required arrays, truncated high key |
Date: | 2024-12-19 16:09:16 |
Message-ID: | CAH2-WzkX3_TYZ+F-HTu4o8nPRkK6MNRLgfJTZ8GYwa07n4RJ_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 18, 2024 at 3:20 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Attached fix addresses the issue by consistently resetting the scan's
> so->scanBehind flag (which might still be set to true from the
> previous page's high key) at the start of _bt_advance_array_keys.
I pushed this fix just now.
I should point out (for the benefit of Tom, or whoever writes the next
set of release notes) that I think that this bug is very unlikely to
occur in practice. Getting wrong answers to queries could only happen
given an index with more than 3 columns, and only for scans with just
the right combination of scan key types. It could also only happen
when the scan advances its array keys using high keys with more than a
single truncated attribute.
Note also that assert-enabled builds would always have seen assertion
failures whenever something like my test case ran. Presumably we'd
have seen a report about such an assertion failure if the underlying
problem was at all common.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-12-19 16:09:35 | Re: connection establishment versus parallel workers |
Previous Message | Andres Freund | 2024-12-19 16:07:25 | Re: Back-patch of: avoid multiple hard links to same WAL file after a crash |