Feedback-ID: id4a34324:Fastmail
Date: Fri, 1 May 2026 13:11:13 -0400
From: Andres Freund <andres@anarazel.de>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, 
	"Andrey M. Borodin" <x4mmm@yandex-team.ru>, Michael Zhilin <m.zhilin@postgrespro.ru>, 
	pgsql-bugs@postgresql.org, Yura Sokolov <y.sokolov@postgrespro.ru>
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B
 varlena datum
Message-ID: <7ckc7oka4bvafkf5bwlqs6ygrhlsbhz25ppozfch7zbuxcx3rf@e4pr4oqenalc>
References: <76bc0dc9-4e43-4cd8-8eec-249b254ed1c9@postgrespro.ru>
 <8C83FCCA-2548-499A-8B1C-96C3D8ADB787@yandex-team.ru>
 <c6f376bf-9896-111f-ccb1-a19dc1381ad0@gmail.com>
 <C8DD7CB5-CFE8-4AF5-88D7-B9F441BB5A8C@yandex-team.ru>
 <0b535249-a00c-a38a-85f6-d5a38c62dd55@gmail.com>
 <CAPpHfdsAs-B7O2_=jGbF+BQzuW3kGSboY9CcxzEOWUgxxZCr5Q@mail.gmail.com>
 <e3a78e44-ec6c-5924-7832-63de3aad3e9b@gmail.com>
 <CAPpHfdtZxhgjZTpaLd--dCxzUOL6tN+aAZPBeTsGKHLkMQAZpw@mail.gmail.com>
 <CAPpHfdu412Z+jh5Oyc1yzWFM0+52h0kSGQKV4=xQ0aT0UeY2BA@mail.gmail.com>
 <CAPpHfdspqdzVdEU2qHMibKn8OwVuLoZZYvKm-m5Ffqy2aMXgGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPpHfdspqdzVdEU2qHMibKn8OwVuLoZZYvKm-m5Ffqy2aMXgGQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/7ckc7oka4bvafkf5bwlqs6ygrhlsbhz25ppozfch7zbuxcx3rf%40e4pr4oqenalc>
Precedence: bulk

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