From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Borisov <pashkin.elfe@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16329: Valgrind detects an invalid read when building a gist
 index with buffering
In-reply-to: 
 <CALT9ZEECCV5m7wvxg46PC-7x-EybUmnpupBGhSFMoAAay+r6HQ@mail.gmail.com>
References: <16329-7a6aa9b6fa1118a1@postgresql.org>
 <ca1f896b-e5d1-53a7-5bc3-9451ab9aca22@gmail.com>
 <e91e45fd-a614-bb87-e9fc-c556c2b95fe5@gmail.com>
 <3dda6945-c147-5afc-7720-38ec6848dafa@gmail.com>
 <10261.1588705157@sss.pgh.pa.us>
 <93ca4540-0016-8217-2b31-535613499987@gmail.com>
 <06f117b8-bbc1-4190-d204-ef329121cbca@gmail.com>
 <CALT9ZEECCV5m7wvxg46PC-7x-EybUmnpupBGhSFMoAAay+r6HQ@mail.gmail.com>
Comments: In-reply-to Pavel Borisov <pashkin.elfe@gmail.com>
	message dated "Mon, 12 Oct 2020 16:30:02 +0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3395317.1602541012.1@sss.pgh.pa.us>
Date: Mon, 12 Oct 2020 18:16:52 -0400
Message-ID: <3395318.1602541012@sss.pgh.pa.us>
Precedence: bulk

Pavel Borisov <pashkin.elfe@gmail.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