Re: Reproducible GIST index corruption under concurrent updates
От | Heikki Linnakangas |
---|---|
Тема | Re: Reproducible GIST index corruption under concurrent updates |
Дата | |
Msg-id | 132baf64-3764-0351-750e-0443e74f1052@iki.fi обсуждение исходный текст |
Ответ на | Re: Reproducible GIST index corruption under concurrent updates (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: Reproducible GIST index corruption under concurrent updates
|
Список | 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 по дате отправления: