Re: Failure in contrib test _int on loach

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> This is a strange failure:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2019-04-05%2005%3A15%3A00
>> [ wrong answers from queries using a GIST index ]

> There are a couple of other recent instances of this failure, on
> francolin and whelk.

Yeah. Given three failures in a couple of days, we can reasonably
guess that the problem was introduced within a day or two prior to
the first one. Looking at what's touched GIST in that time frame,
suspicion has to fall heavily on 9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b.

If I had to bet, I'd bet that there's something wrong with the
machinations described in the commit message:

For GiST, the LSN-NSN interlock makes this a little tricky. All pages must
be marked with a valid (i.e. non-zero) LSN, so that the parent-child
LSN-NSN interlock works correctly. We now use magic value 1 for that during
index build. Change the fake LSN counter to begin from 1000, so that 1 is
safely smaller than any real or fake LSN. 2 would've been enough for our
purposes, but let's reserve a bigger range, in case we need more special
values in the future.

I'll go add this as an open issue.

regards, tom lane