BUG #19780: gtsvector_picksplit() reads uninitialized data when called with three entries
The following bug has been logged on the website:
Bug reference: 19780
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 19rc1
Operating system: Ubuntu 24.04
Description:
The following script:
CREATE TABLE t (i tsvector, j tsvector);
CREATE INDEX t_idx ON t USING gist (i tsvector_ops (siglen = '1800'), j
tsvector_ops);
INSERT INTO t SELECT (SELECT string_agg(g::text, ' ')::tsvector FROM
generate_series(1, 200) g), 'x'::tsvector FROM generate_series(1, 4);
INSERT INTO t SELECT (SELECT string_agg(g::text, ' ')::tsvector FROM
generate_series(1, 200) g) || 'a', 'x'::tsvector;
being executed under Valgrind, triggers:
==00:00:00:57.066 1678143== Conditional jump or move depends on
uninitialised value(s)
==00:00:00:57.066 1678143== at 0x48CBC35: gtsvector_picksplit
(tsgistidx.c:685)
==00:00:00:57.066 1678143== by 0x493208E: FunctionCall2Coll (fmgr.c:1163)
==00:00:00:57.066 1678143== by 0x41409A3: gistUserPicksplit
(gistsplit.c:433)
==00:00:00:57.066 1678143== by 0x414127B: gistSplitByKey
(gistsplit.c:697)
==00:00:00:57.066 1678143== by 0x4141504: gistSplitByKey
(gistsplit.c:747)
==00:00:00:57.066 1678143== by 0x4134199: gistSplit (gist.c:1483)
==00:00:00:57.066 1678143== by 0x4131D58: gistplacetopage (gist.c:316)
==00:00:00:57.066 1678143== by 0x4133D6D: gistinserttuples (gist.c:1310)
==00:00:00:57.066 1678143== by 0x4133CC7: gistinserttuple (gist.c:1263)
==00:00:00:57.066 1678143== by 0x413310D: gistdoinsert (gist.c:892)
==00:00:00:57.067 1678143== by 0x41319E7: gistinsert (gist.c:191)
==00:00:00:57.067 1678143== by 0x4184D62: index_insert (indexam.c:231)
==00:00:00:57.067 1678143==
Reproduced on REL_14_STABLE .. master.
Hi Alexander,
Thanks for the report. With only two entries, the cache of the second
one is used before it is filled.
Your two column case is harmless. With one column, the index can miss
rows until REINDEX.
The attached patch fills the cache earlier and adds a test.
Thanks,
Shihao
Hi,
On Wed, 4 Nov 2026 at 11:13, shihao zhong <zhong950419@gmail.com> wrote:
Thanks for the report. With only two entries, the cache of the second
one is used before it is filled.
+1
Your two column case is harmless. With one column, the index can miss
rows until REINDEX.The attached patch fills the cache earlier and adds a test.
Thanks for the patch, it looks good to me.
Regards,
Ayush