Re: Bug in nbtree SAOP scans with non-required arrays, truncated high key

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

In response to

Browse pgsql-hackers by date

  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