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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>,
Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-04-29T00:54:07Z
Lists: pgsql-bugs
Attachments
- v3-0001-Ensure-we-allocate-NAMEDATALEN-bytes-for-names-in.patch (text/plain) patch v3-0001
On Fri, 26 Apr 2024 at 03:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I do not like testing "atttypid == NAMEOID" one bit. As noted, > that will fail on domains over name. It will also result in > unnecessary work when reading non-btree indexes that contain > name, since I don't think anything else has the same hack > that btree name_ops does (grep for cstring in pg_opclass.dat). > I think the correct thing is to see whether the index opclass > for the column is btree name_ops. We don't seem to have an > oid_symbol macro for that, but it shouldn't be hard to add, > at least in HEAD. On looking at the relcache code, I don't see anywhere that we store the opclass Oid in RelationData. IndexSupportInitialize() only records the opcfamily and opcintype. Assuming we can't add new fields to RelationData in the backbranches, is there a reason why we can't check for rd_opfamily of TEXT_BTREE_FAM_OID and rd_opcintype of NAMEOID? I've attached an updated patch that does it that way and also did a round of commenting the code. 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