Re: Failure in contrib test _int on loach

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Failure in contrib test _int on loach
Дата
Msg-id 1346.1554476502@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Failure in contrib test _int on loach  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: Failure in contrib test _int on loach  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: monitoring CREATE INDEX [CONCURRENTLY]
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: FETCH FIRST clause PERCENT option