Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>,
Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2024-04-24T02:25:56Z
Lists: pgsql-bugs
Attachments
- v2-0001-Ensure-we-allocate-NAMEDATALEN-bytes-for-names-in.patch (text/plain) patch v2-0001
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. David
Commits
-
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
- e3f9dcabd6f2 12.19 landed
- 0a34bcd0c23e 13.15 landed
- e6b0efc65e58 14.12 landed
- 52f21f928732 15.7 landed
- 68d358545037 16.3 landed
- a63224be49b8 17.0 landed