From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Borodin <x4mmm@yandex-team.ru>
cc: Pavel Borisov <pashkin.elfe@gmail.com>,
        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: <0931D3ED-77BA-407C-8C5B-2FBD624ED3A0@yandex-team.ru>
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>
 <3395318.1602541012@sss.pgh.pa.us>
 <0931D3ED-77BA-407C-8C5B-2FBD624ED3A0@yandex-team.ru>
Comments: In-reply-to Andrey Borodin <x4mmm@yandex-team.ru>
	message dated "Thu, 22 Oct 2020 10:50:48 +0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <275236.1603375317.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Oct 2020 10:01:57 -0400
Message-ID: <275237.1603375317@sss.pgh.pa.us>
Precedence: bulk

Andrey Borodin <x4mmm@yandex-team.ru> writes:
>> 13 =D0=BE=D0=BA=D1=82. 2020 =D0=B3., =D0=B2 03:16, Tom Lane <tgl@sss.pg=
h.pa.us> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>> 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.

> I think we should use not entropy-based tie breaker in GiST. We can extr=
act some randomness from tuples using hash.
> I'd be much happier if GiST behaviour was deterministic.

If we started using our own PRNG, we could very easily make the "random"
sequence be the same in every GiST build --- again, see GEQO for prior
art.  I'm a little suspicious of trying to pull some entropy out of the
tuples themselves: that seems like it'd be tremendously prone to cross-
platform and cross-version behavioral differences.

			regards, tom lane