Re: Failure in contrib test _int on loach
| От | Andrey Lepikhov |
|---|---|
| Тема | Re: Failure in contrib test _int on loach |
| Дата | |
| Msg-id | 8393eae3-1eda-157c-e363-baa166ba65fa@postgrespro.ru обсуждение исходный текст |
| Ответ на | Re: Failure in contrib test _int on loach (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: Failure in contrib test _int on loach
|
| Список | pgsql-hackers |
On 10/04/2019 20:25, Heikki Linnakangas wrote: > 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? Based on Anastasia's idea i prepare alternative solution to fix the bug (see attachment). It utilizes the idea of linear increment of LSN/NSN. WAL write process is used for change NSN value to 1 for each block of index relation. I hope this can be a fairly clear and safe solution. -- Andrey Lepikhov Postgres Professional https://postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: