Re: [PATCH] Check that index can return in get_actual_variable_range()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Maxime Schoemans <maxime(dot)schoemans(at)enterprisedb(dot)com>, Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Subject: Re: [PATCH] Check that index can return in get_actual_variable_range()
Date: 2025-10-28 09:20:39
Message-ID: 2cc73c0a-e0dd-4f98-be9f-469c4f1df65e@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.09.25 16:38, Maxime Schoemans wrote:
> On 19 Sep 2025, at 10:20, Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
> wrote:
>
>> Yes, this is how we typically test cases like this. IMO adding a test
>> module would be helpful. It can be reused for other scenarios.
>
> Here is an updated patch set.
> - 0001 is unchanged.
> - 0002 contains the module that tests the correct behavior of
> get_actual_variable_range for non-returning ordering indices.
> It contains a copy of the btree handler function with its index-only
> capabilities removed. If you apply patch 0002 on master without 0001,
> you will see that the test returns an error (ERROR: no data returned
> for index-only scan) as it tries to use the index in
> get_actual_variable_range, which shouldn’t be the case.

I have committed the first patch.

The test suite is probably a bit too bulky for testing this particular
niche behavior. Also, it doesn't work with assertions enabled because
of the hardcoded BTREE_AM_OID in src/include/access/nbtree.h. So I
don't plan to commit that. But it's good to have it in the archive, and
perhaps it can be part of a larger test suite for the index AM API at
some point in the future.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kukushkin 2025-10-28 09:24:46 Re: tiny step toward threading: reduce dependence on setlocale()
Previous Message Bertrand Drouvot 2025-10-28 08:58:03 Re: Question about InvalidatePossiblyObsoleteSlot()