Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum - Mailing list pgsql-bugs

From Andres Freund
Subject Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Date
Msg-id 7ckc7oka4bvafkf5bwlqs6ygrhlsbhz25ppozfch7zbuxcx3rf@e4pr4oqenalc
Whole thread
In response to Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Zhongpu Chen
Date:
Subject: Re: Character with byte sequence 0xa2 0xa3 in encoding "EUC_CN" has no equivalent in encoding "UTF8"
Next
From: Andrey Borodin
Date:
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum