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

> 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.