Message-ID: <5664e428-4473-d51f-363d-c143c39d57e3@gmail.com>
Date: Tue, 30 Apr 2024 18:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17855: Uninitialised memory used when the name type value
 processed in binary mode of Memoize
Content-Language: en-US
To: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <17855-5f523e0f9769a566@postgresql.org>
 <CAApHDvqwwdO1EAo-6osu-LtTk1SD2iQjLQXhVd7Wamc-JfhfrQ@mail.gmail.com>
 <CAApHDvokmLEriy3+4vB0KjCQip5pMq0g_JJX-wHNDvBJKukr6w@mail.gmail.com>
 <CAApHDvqNo_7yipfLjVXatUUosEkKZrdhHxAObPuxSat8UQaUTw@mail.gmail.com>
 <b2a382d6-d261-fdb6-176c-d0cdbf63dce8@gmail.com>
 <CAApHDvqqvkorexCuVkSJ16LcqGKfUdLAn3Y+YsqKNT3Pe56oOA@mail.gmail.com>
 <3943232.1714060238@sss.pgh.pa.us>
 <CAApHDvpW3ZEyTyogjD6qJsnuTFujLk3yTyCPX-to7VhftkrakQ@mail.gmail.com>
 <c898e301-ea62-e551-bfbc-2b7579150c14@gmail.com>
 <1228403.1714400922@sss.pgh.pa.us>
 <CAApHDvrG=X6YK3WajkvybT5k=nnWt3W+yr8tMcFHYVVjej8zKw@mail.gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CAApHDvrG=X6YK3WajkvybT5k=nnWt3W+yr8tMcFHYVVjej8zKw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/5664e428-4473-d51f-363d-c143c39d57e3%40gmail.com>
Precedence: bulk

Hello David,

30.04.2024 03:48, David Rowley wrote:
> On Tue, 30 Apr 2024 at 02:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> One bit of research that needs to be done is whether btree will
>> truncate an "include"'d column of type name.  I think it will not,
>> because that behavior is driven by the opclass and there isn't one
>> for an included column, but it wouldn't hurt to check.  If so,
>> just restricting these setup loops to consider only indnkeyatts
>> columns should fix this.
> I did that research in the form of setting a breakpoint in
> index_deform_tuple() and verified the tup->t_info & 0xFFF grows by
> 64-bytes for each extra name column I INCLUDE.  Also verified those
> extra bytes are all zero'd

Yes, I saw the same with pageinspect.

I could not find cases (I've tested also ranges and arrays based on the
name type) where the v4 behaves incorrectly, so I think it solves the
problem.

As a side note, perhaps this addition:
+#include "catalog/pg_opfamily_d.h"
is not needed for the current implementation.

Thank you for the fix!

Best regards,
Alexander