Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum

Hi,

Thank you, Andrey, for review and advice!

Here is rebased version (v2) of patch supposed to make CF bot happy.

Best regards,
   Michael

On 1/8/24 17:34, Andrey M. Borodin wrote:
> Hi Alexander!
>
> I think both cases are very interesting and deserve two separate bug items.
>
>> On 14 Dec 2023, at 22:17, Alexander Lakhin<exclusion@gmail.com>  wrote:
>>
>>
>> By changing the storage mode for a column, you can also get another error:
>> CREATE TABLE t(f1 text);
>> CREATE INDEX t_idx ON t(f1);
>> INSERT INTO t VALUES(repeat('1234567890', 1000));
>> ALTER TABLE t ALTER COLUMN f1 SET STORAGE plain;
>>
>> CREATE EXTENSION amcheck;
>> SELECT bt_index_check('t_idx', true);
>>
>> ERROR:  index row requires 10016 bytes, maximum size is 8191
>>
> I think In this case we should warn user that index contains tuples with datums that are not insertable anymore. And abort heapallindexed.
>
>
>> On 8 Jan 2024, at 00:00, Alexander Lakhin<exclusion@gmail.com>  wrote:
>>
>> What is your opinion regarding similar failures, which are not addressed
>> by the patch? Besides the case shown above, there is another one:
>> CREATE TABLE tbl(i int4, t text);
>> ALTER TABLE tbl ALTER COLUMN t SET STORAGE plain;
>> CREATE INDEX tbl_idx ON tbl (t, i) WITH (fillfactor = 10);
>> INSERT INTO tbl SELECT g, repeat('Test', 250) FROM generate_series(1, 130) g;
>> ALTER TABLE tbl ALTER COLUMN t SET STORAGE extended;
>>
>> CREATE EXTENSION amcheck;
>> SELECT bt_index_check('tbl_idx', true);
>>
>> ERROR:  heap tuple (0,1) from table "tbl" lacks matching index tuple within index "tbl_idx"
>> HINT:  Retrying verification using the function bt_index_parent_check() might provide a more specific error.
> IMO In this case we should handle VARATT_IS_EXTENDED in bt_normalize_tuple().
>
> BTW CI fails of the original patch ITT are related to the fact that COPY in\out file is created in PG_ABS_SRCDIR instead of PG_ABS_BUILDDIR. In an off-list conversation I recommended Michael to mimic tests regress/largeobject.sql. Though, there might be better ideas.
>
> Thanks!
>
>
> Best regards, Andrey Borodin.
>

-- 
Michael Zhilin
Postgres Professional
+7(925)3366270
https://www.postgrespro.ru