10.04.2019 18:25, Heikki Linnakangas writes:
> 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?
>
From what I understand,
the only reason for grandparent's split during gistbuild is the
insertion of the newtup returned by gistgetadjusted().
After we stepped up the stack, we will do gistchoose() to choose new
correct child,
adjust the downlink key and insert it into grandparent. If this
insertion caused split, we will recursively follow the same codepath
and set stack->retry_from_parent again.
So it is possible, but it doesn't require any extra algorithm changes.
I didn't manage to generate dataset to reproduce grandparent split.
Though, I do agree that it's worth checking out. Do you have any ideas?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company