Re: Failure in contrib test _int on loach

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Failure in contrib test _int on loach
Дата
Msg-id d347c092-ae74-d515-8c3d-4592cc131111@iki.fi
обсуждение исходный текст
Ответ на Re: Failure in contrib test _int on loach  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Ответы Re: Failure in contrib test _int on loach  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Re: Failure in contrib test _int on loach  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Список pgsql-hackers
On 09/04/2019 19:11, Anastasia Lubennikova wrote:
> 05.04.2019 19:41, Anastasia Lubennikova writes:
>> In attachment, you can find patch with a test that allows to reproduce
>> the bug not randomly, but on every run.
>> Now I'm trying to find a way to fix the issue.
> 
> The problem was caused by incorrect detection of the page to insert new
> tuple after split.
> If gistinserttuple() of the tuple formed by gistgetadjusted() had to
> split the page, we must to go back to the parent and
> descend back to the child that's a better fit for the new tuple.
> 
> Previously this was handled by the code block with the following comment:
> 
> * Concurrent split detected. There's no guarantee that the
> * downlink for this page is consistent with the tuple we're
> * inserting anymore, so go back to parent and rechoose the best
> * child.
> 
> After introducing GistBuildNSN this code path became unreachable.
> To fix it, I added new flag to detect such splits during indexbuild.

Isn't it possible that the grandparent page is also split, so that we'd 
need to climb further up?

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Berserk Autovacuum (let's save next Mandrill)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: block-level incremental backup