Re: Failure in contrib test _int on loach - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Failure in contrib test _int on loach
Date
Msg-id 1346.1554476502@sss.pgh.pa.us
Whole thread Raw
In response to Re: Failure in contrib test _int on loach  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Failure in contrib test _int on loach
List pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On Fri, Apr 5, 2019 at 2:02 AM Thomas Munro <thomas.munro@gmail.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: monitoring CREATE INDEX [CONCURRENTLY]
Next
From: Tomas Vondra
Date:
Subject: Re: FETCH FIRST clause PERCENT option