| From: | Maxime Schoemans <maxime(dot)schoemans(at)enterprisedb(dot)com> |
|---|---|
| To: | 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-09-18 14:51:39 |
| Message-ID: | D65B6A44-429E-4D75-8E96-97A2C9B860EA@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18 Sep 2025, at 14:31, Aleksander Alekseev <aleksander(at)tigerdata(dot)com> wrote:
> Can you think of any test cases we can add to the code base?
The only idea I have would be adding a new index module in src/test/modules that has this particular property and have a test that will hit get_actual_variable_range().
For example, it could be a new access method that is a copy of btree, but whose amcanreturn property is null and that specifically sets scan->xs_itup to null in amgettuple.
Without the patch, such a test would fail with 'ERROR: no data returned for index-only scan’, while with the patch it would pass.
Best,
Maxime Schoemans
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-09-18 14:56:35 | Re: REPACK and naming |
| Previous Message | Karina Litskevich | 2025-09-18 14:25:00 | Re: pg_stat_statements: faster search by queryid |