Message-ID: <178d5d4c-969b-da9f-37a9-34bf6693d1ea@gmail.com>
Date: Wed, 24 Apr 2024 16: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>, Robert Haas <robertmhaas@gmail.com>
Cc: 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>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CAApHDvqqvkorexCuVkSJ16LcqGKfUdLAn3Y+YsqKNT3Pe56oOA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/178d5d4c-969b-da9f-37a9-34bf6693d1ea%40gmail.com>
Precedence: bulk

Hello David.

24.04.2024 05:25, David Rowley wrote:
> On Sat, 9 Sept 2023 at 20:00, Alexander Lakhin <exclusion@gmail.com> wrote:
>> I've stumbled upon this issue one more time. With a query like this:
>> CREATE TABLE t(id integer, node name);
>> CREATE INDEX t_id_node_idx ON t(id, node);
>> INSERT INTO t VALUES (1, 'node1');
>>
>> (Note that this time the error is triggered without the Memoize node.)
> Yeah, it's really not a Memoize bug. It's an Index Only Scan bug.
> I've added Robert to get his views.
>
>> Maybe it makes sense to register the proposed patch on the commitfest at
>> least to keep it in sight?
> I've attached another patch which uses another method to fix this, per
> an idea from Andres Freund.  I'd class it as a hack, but I don't have
> any better ideas aside from the mammoth task of making name variable
> length.  Indexes on name typed columns simply don't store all 64 bytes
> of the name, so it's not safe to have code that assumes a name Datum
> points to 64 bytes. The patch makes it so such a Datum *will* point to
> 64 bytes.  I've tried to do this as cheaply as possible by saving the
> indexes to name columns in a new array in IndexOnlyScanState.  That
> should make the overhead very small when indexes don't contain any
> name-typed columns.

I've tested this patch with an additional #include in nodeIndexonlyscan.c
(for namestrcpy), it works, but I'm unsure about the check for NAMEOID —
it seems like the fix could break for a type based on name. Say, with:
CREATE DOMAIN named AS name;
CREATE TABLE t(id integer, node named);
CREATE INDEX t_id_node_idx ON t(id, node);
INSERT INTO t VALUES (1, 'node1');

SELECT array_agg(node ORDER BY node) AS node_list FROM t GROUP BY id;

I still get the Valgrind complaint.

Best regards,
Alexander