Re: Reproducible GIST index corruption under concurrent updates - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: Reproducible GIST index corruption under concurrent updates
Date
Msg-id 132baf64-3764-0351-750e-0443e74f1052@iki.fi
Whole thread Raw
In response to Re: Reproducible GIST index corruption under concurrent updates  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Reproducible GIST index corruption under concurrent updates
List pgsql-bugs
On 19/01/2021 19:12, Andrey Borodin wrote:
>> 19 янв. 2021 г., в 16:15, Duncan Sands <duncan.sands@deepbluecap.com> написал(а):
>>
>> Enjoy!
> 
> Thanks!
> It reproduces on my machine. Seems like all tuples are indexed, but some root downlinks are not adjusted properly.
Probably,after concurrent split.
 

This is reproducable down to v12. I bisected it to this commit:

commit e2e992c93145cfc0e3563fb84efd25b390a84bb9 (refs/bisect/bad)
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Wed Jul 24 20:24:05 2019 +0300

     Refactor checks for deleted GiST pages.

     The explicit check in gistScanPage() isn't currently really 
necessary, as
     a deleted page is always empty, so the loop would fall through without
     doing anything, anyway. But it's a marginal optimization, and it 
gives a
     nice place to attach a comment to explain how it works.

     Backpatch to v12, where GiST page deletion was introduced.

     Reviewed-by: Andrey Borodin
     Discussion: 
https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru

I'll dig deeper tomorrow.

- Heikki



pgsql-bugs by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Reproducible GIST index corruption under concurrent updates
Next
From: Heikki Linnakangas
Date:
Subject: Re: Reproducible GIST index corruption under concurrent updates