Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
От | Alexander Lakhin |
---|---|
Тема | Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize |
Дата | |
Msg-id | 5664e428-4473-d51f-363d-c143c39d57e3@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize (David Rowley <dgrowleyml@gmail.com>) |
Список | 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
В списке pgsql-bugs по дате отправления: