Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering
От | Noah Misch |
---|---|
Тема | Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering |
Дата | |
Msg-id | 20230330044245.GA449998@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Wed, Mar 29, 2023 at 06:21:38PM -0400, Tom Lane wrote: > *** a/src/test/regress/sql/gist.sql > --- b/src/test/regress/sql/gist.sql > *************** select p from gist_tbl order by circle(p > *** 170,175 **** > --- 170,180 ---- > select p from gist_tbl order by circle(p,1) <-> point(0,0) limit 1; > > -- Force an index build using buffering. > + insert into gist_tbl > + select box(point(0.05*i, 0.05*i), point(0.05*i, 0.05*i)), > + point(0.05*i, 0.05*i), > + circle(point(0.05*i, 0.05*i), 1.0) > + from generate_series(10001,30000) as i; > create index gist_tbl_box_index_forcing_buffering on gist_tbl using gist (p) > with (buffering=on, fillfactor=50); > > The question is whether it's worth the extra test cycles forevermore. > On my machine, the time for the gist test script goes from ~400ms to > ~600ms. That's still less than some of the concurrent scripts (brin, > privileges, and join_hash all take more than that for me), so maybe > it's fine. But it seems like a lot for a change that doesn't move the > raw code coverage results by even one line. I say +200ms is fine. This thread is a reminder of the limits of raw code coverage as a measure of tests. (I expect this will add tens of minutes to the soft-float buildfarm animal runs, but they deserve it.)
В списке pgsql-bugs по дате отправления: