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 | c898e301-ea62-e551-bfbc-2b7579150c14@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
|
Список | pgsql-bugs |
Hello David, 29.04.2024 03:54, David Rowley wrote: > 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. With the v3 patch applied, `make check` fails for me under Valgrind: ok 66 + create_index 33585 ms not ok 67 + create_index_spgist 14446 ms # (test process exited with exit code 2) ==00:00:04:57.033 4152513== Invalid read of size 4 ==00:00:04:57.033 4152513== at 0x456499: ExecInitIndexOnlyScan (nodeIndexonlyscan.c:657) ==00:00:04:57.033 4152513== by 0x435EE6: ExecInitNode (execProcnode.c:225) ==00:00:04:57.033 4152513== by 0x459780: ExecInitLimit (nodeLimit.c:477) ... ==00:00:04:57.033 4152513== Address 0x73263b4 is 612 bytes inside a recently re-allocated block of size 1,024 alloc'd ==00:00:04:57.033 4152513== at 0x4848899: malloc (vg_replace_malloc.c:381) ==00:00:04:57.033 4152513== by 0x7A7DFC: AllocSetContextCreateInternal (aset.c:444) ==00:00:04:57.033 4152513== by 0x775644: RelationInitIndexAccessInfo (relcache.c:1481) ==00:00:04:57.033 4152513== by 0x775E4B: RelationBuildDesc (relcache.c:1207) ... ==00:00:04:57.033 4152513== ==00:00:04:57.033 4152513== Exit program on first error (--exit-on-first-error=yes) 2024-04-29 12:32:14.965 UTC postmaster[4109162] LOG: server process (PID 4152513) exited with exit code 1 2024-04-29 12:32:14.965 UTC postmaster[4109162] DETAIL: Failed process was running: SELECT p, dist FROM quad_point_tbl_ord_seq1 ORDER BY p <-> '0,0' LIMIT 10; The quad_point_tbl_ord_seq1 index is defined as CREATE INDEX ON quad_point_tbl_ord_seq1 USING spgist(p) INCLUDE(dist); Best regards, Alexander
В списке pgsql-bugs по дате отправления: