From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16329: Valgrind detects an invalid read when building a gist index with buffering |
Date: | 2020-10-12 22:16:52 |
Message-ID: | 3395318.1602541012@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> Also, there is a minor correction for the case of covering index where only
> part of the columns are keys, others are just INCLUDE columns.
Yeah, that's clearly a bug, and it reinforces the point about wanting
more thorough test coverage of this area.
I pushed the bug fix, but not yet the test addition, because I'm not
very happy about the latter:
1. It nearly triples the runtime of gist.sql, from ~650 ms to ~1700 ms
on my machine. That's a pretty bad increase for something we're
proposing to drop into the core regression tests. Given that this is
hardly the only index build in that test, I wonder why it's so much
(but I did not look for the reason).
2. The test exposed the gistRelocateBuildBuffersOnSplit bug only about
one time in ten for me. I suppose this is due to the random split
choices gistchoose makes for equally-good tuples, so it's not terribly
surprising; but it is problematic for a test that we're hoping to use
to provide reliable code coverage.
I'm not really sure what we could do about #2. Perhaps, instead of
relying on random(), we could make gistchoose() use our own PRNG and
then invent a debugging function that forces the seed to a known value.
(GEQO already does something similar, although I'd not go as far as
exposing the seed as a GUC. Resetting it via some quick-hack C
function in regress.c would be enough IMO.) Or perhaps gist.sql could
be adjusted so that the test data is less full of equally-good tuples.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bryn Llewellyn | 2020-10-13 00:01:41 | Wrong results from function that selects from vier after "created or replace" |
Previous Message | adam grech | 2020-10-12 21:23:30 | Re: BUG #16667: COMMIT AND CHAIN does not udpates database metrics ie. xact_commit |