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

Hi,

On 2024-03-23 13:37:04 +0200, Alexander Korotkov wrote:
> @@ -2981,6 +2982,18 @@ bt_normalize_tuple(BtreeCheckState *state, IndexTuple itup)
> ItemPointerGetBlockNumber(&(itup->t_tid)),
> ItemPointerGetOffsetNumber(&(itup->t_tid)),
> RelationGetRelationName(state->rel))));
> + else if (!VARATT_IS_COMPRESSED(DatumGetPointer(normalized[i])) &&
> + VARSIZE(DatumGetPointer(normalized[i])) > TOAST_INDEX_TARGET &&
> + (att->attstorage == TYPSTORAGE_EXTENDED ||
> + att->attstorage == TYPSTORAGE_MAIN))
> + {
> + /*
> + * This value will be compressed by index_form_tuple() with the
> + * current storage settings. We may be here because this tuple
> + * was formed with different storage settings. So, force forming.
> + */
> + formnewtup = true;
> + }
> else if (VARATT_IS_COMPRESSED(DatumGetPointer(normalized[i])))
> {
> formnewtup = true;

While hacking on something, I added an assertion to VARSIZE() that the
argument is actually a VARATT_4B (which it assumes). Worked everywhere, except
for this caller: amcheck/regress fails, because sometimes the varlena is
actually a short/1B varlena.

Note that VARSIZE_4B on a short datum will give you completely bogus
answers. E.g. in the case that failed the assertion, VARSIZE_1B() is 2, but
VARSIZE_4B(PTR) is 7681.

diff --git i/contrib/amcheck/verify_nbtree.c w/contrib/amcheck/verify_nbtree.c
index b74ab5f7a05..0b87109fde3 100644
--- i/contrib/amcheck/verify_nbtree.c
+++ w/contrib/amcheck/verify_nbtree.c
@@ -2889,6 +2889,7 @@ bt_normalize_tuple(BtreeCheckState *state, IndexTuple itup)
ItemPointerGetOffsetNumber(&(itup->t_tid)),
RelationGetRelationName(state->rel))));
else if (!VARATT_IS_COMPRESSED(DatumGetPointer(normalized[i])) &&
+ !VARATT_IS_SHORT(DatumGetPointer(normalized[i])) &&
VARSIZE(DatumGetPointer(normalized[i])) > TOAST_INDEX_TARGET &&
(att->attstorage == TYPSTORAGE_EXTENDED ||
att->attstorage == TYPSTORAGE_MAIN))

Fixes the assert failure.

I guess I find it aesthetically a bit unpleasing to check the same stuff so
many times for one varlena :). Not that it should matter performance-wise
here...

Greetings,

Andres Freund