Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
От | Andres Freund |
---|---|
Тема | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
Дата | |
Msg-id | 20220114021549.m6ugihzjmsunv3jd@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
Список | pgsql-bugs |
On 2022-01-12 13:05:45 -0800, Peter Geoghegan wrote: > On Wed, Jan 12, 2022 at 11:25 AM Andres Freund <andres@anarazel.de> wrote: > > > Any blockers? > > > > I'm just struggling with / procrastinating on the commit message, tbh. The > > whole issue is kinda complicated to explain... :/ After struggling some more, I *finally* pushed the fix and the new assertions. Thanks for the bug report, investigation, review, etc! > I think that it would make sense for the commit message to frame the > problem as: pruneheap.c doesn't take sufficient care when traversing > HOT chains to determine their full extent, for the purposes of > pruning. There was a general lack of robustness, and the snapshot > scalability work happened to run into that, resulting in hot chain > corruption under very specific conditions. > > If I was in your position I think I would resist framing the problem > in this way; I'd probably be concerned that it would come off as > shifting the blame elsewhere. This high level explanation of things > makes the most sense to me, though. Surely that's the most important > thing. Thanks!
В списке pgsql-bugs по дате отправления: