MIME-Version: 1.0
References: <7bdbe559-d61a-4ae4-a6e1-48abdf3024cc@postgrespro.ru>
 <0FDE2089-D306-4CBB-AD1F-EC4B419E3B33@yandex-team.ru> <e6d20179-ddbd-3376-a7f5-4831df7d6b60@gmail.com>
 <49BBA065-4C9A-4E50-9048-B457907FF219@yandex-team.ru> <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>
In-Reply-To: <0b535249-a00c-a38a-85f6-d5a38c62dd55@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Wed, 20 Mar 2024 12:24:55 +0200
Message-ID: <CAPpHfdsAs-B7O2_=jGbF+BQzuW3kGSboY9CcxzEOWUgxxZCr5Q@mail.gmail.com>
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B
 varlena datum
To: Alexander Lakhin <exclusion@gmail.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Michael Zhilin <m.zhilin@postgrespro.ru>, 
	pgsql-bugs@postgresql.org, Yura Sokolov <y.sokolov@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfdsAs-B7O2_%3DjGbF%2BBQzuW3kGSboY9CcxzEOWUgxxZCr5Q%40mail.gmail.com>
Precedence: bulk

Hi!


On Fri, Jan 26, 2024 at 9:00=E2=80=AFAM Alexander Lakhin <exclusion@gmail.c=
om> wrote:
>
> 23.01.2024 21:09, Andrey M. Borodin wrote:
> > PFA draft fixes for both this errors. Alexander, Michael, Jian, what do=
 you think?
> >
> > I did not touch anything in first step - fix for original bug in this t=
hread. However, I think that comments from Jian He worth incorporating into=
 the fix.
> >
>
> I''m confused by a NOTICE added, as it printed now even for cases, which
> worked before, for example:
> CREATE TABLE t(f1 text);
> CREATE INDEX idx ON t(f1);
> INSERT INTO t VALUES(repeat('1234567890', 1000));
> SELECT bt_index_check('idx', true);
> NOTICE:  Index contain tuples that cannot fit into index page, if toasted=
 with current toast policy
>   bt_index_check
> ----------------
>
> (1 row)


Right, the patch number 0003 looks wrong to me.  It uses
heap_compute_data_size() to compute the size of the future index
tuple.  But heap_compute_data_size() doesn't apply any compression on
the attributes.  I suggest instead we just need to have a version of
index_form_tuple() that reports an oversized tuple in a return value
rather than throwing the error.

BTW, 0001 and 0002 look good to me.  I'm going to push them if no objection=
s.

------
Regards,
Alexander Korotkov