Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum |
Дата | |
Msg-id | CAH2-WzmLVPByK+5LMHQynn_M45vFot7YXWLNT5aAwvBBve_Ezg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
|
Список | pgsql-bugs |
On Fri, Nov 12, 2021 at 3:56 PM Andres Freund <andres@anarazel.de> wrote: > > Why is that simpler than a boolean array, which represents whether or > > not the item has had its heap_prune_record_unused() call yet (if it's > > a tuple with storage)? > > Well, your change is basically a new approach of pruning - a much better > one. But it's a larger change than just eliminating the repeated HTSV calls so > that they cannot change over time. That'd be ~10-15 lines. Before Wednesday, I had no idea that a HEAPTUPLE_DELETE_IN_PROGRESS could turn to DEAD during VACUUM/pruning at all. And so I now have to wonder: what else don't I know? There is one thing that I am fairly confident of here: the HOT chain validation stuff is very robust. Experience has shown the invariants to be very reliable (and if they're not reliable then we're in big trouble anyway). The invariants can be leveraged to make the pruning fix robust against both the issue we know about, and hypothetical undiscovered issues that also may affect pruning. The overall risk seems much lower with my patch. It isn't the smallest possible patch, certainly, but that doesn't seem all that relevant, given the specifics of the situation. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: