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
Re: Failure in contrib test _int on loach |
Список | 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 по дате отправления: