Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
Alexander Law <exclusion@gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2024-04-30T15:00:00Z
Lists: pgsql-bugs
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
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