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

From Andrey Borodin
Subject Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Date
Msg-id DA0695AB-4A40-4272-BE64-D22F81F7713B@yandex-team.ru
Whole thread
In response to Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum  (Andres Freund <andres@anarazel.de>)
Responses Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
List pgsql-bugs

> On 1 May 2026, at 22:11, Andres Freund <andres@anarazel.de> wrote:
>
> 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.

I remember the original code was taken from somewhere else because there
was already some instances like this:

/*
 * If value is above size target, and is of a compressible datatype,
 * try to compress it in-line.
 */
if (!VARATT_IS_EXTENDED(DatumGetPointer(untoasted_values[i])) &&
VARSIZE(DatumGetPointer(untoasted_values[i])) > TOAST_INDEX_TARGET &&
(att->attstorage == TYPSTORAGE_EXTENDED ||
att->attstorage == TYPSTORAGE_MAIN))
{

I don't have VARATT_IS_EXTENDED vs VARATT_IS_COMPRESSED vs VARATT_IS_SHORT
business in my warm cache right away, but I'll try to remember what it means soon.


Best regards, Andrey Borodin.


pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Next
From: Andres Freund
Date:
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum