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

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(at)gmail(dot)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(at)gmail(dot)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.