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
