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

On Sun, May 3, 2026 at 9:17 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > On 2 May 2026, at 00:41, Andres Freund <andres@anarazel.de> wrote:
> >
> > This is checking (as you noted) !VARATT_IS_EXTENDED, whereas the
> > bt_normalize_tuple() code is checking !VARATT_IS_COMPRESSED.
> >
> > VARATT_IS_EXTENDED() will return true for short varlenas (because it's not a
> > standard 4 byte uncompressed varlena), whereas VARATT_IS_COMPRESSED() will
> > return false for a short varlena (since it's not compressed).
> >
> > I didn't find other instanes of similar code that uses !VARATT_IS_COMPRESSED.
>
> As far as I understand
>
> !VARATT_IS_COMPRESSED(DatumGetPointer(normalized[i])) && !VARATT_IS_SHORT(DatumGetPointer(normalized[i]))
>
> is exactly
>
> !VARATT_IS_EXTENDED(DatumGetPointer(untoasted_values[i]))
>
> Which is what was proposed in v2 patch. But later was changed to !VARATT_IS_COMPRESSED().
> As I understood it was done to further strengthen normalization.
>
> So the intent might be that short varatts need normalization in some cases. But we have no tests that show such a case.
> I tried to build a problematic storage alternation like [0], but everything works nicely.
>
> So I propose something in a line with attached patch.
>
>
> Best regards, Andrey Borodin.
>
> [0] https://github.com/postgres/postgres/blob/master/contrib/amcheck/sql/check_btree.sql#L170-L172

AFAICS, this is correct.  However, I propose an alternative approach:
use VARSIZE_ANY().  This might be a bit slower, but looks more
intuitive to me.

------
Regards,
Alexander Korotkov
Supabase