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 | 20211112235605.4gabo7ooojefuxn3@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
|
Список | pgsql-bugs |
Hi, On 2021-11-12 15:47:45 -0800, Peter Geoghegan wrote: > On Fri, Nov 12, 2021 at 3:31 PM Andres Freund <andres@anarazel.de> wrote: > > I wonder if we should try to go for something considerably simpler for 14. How > > about having a new array that just stores the HTSV state for every > > ItemIdIsNormal(). For simplicity, we could populate that array eagerly in a > > separate loop. > > 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. > > That'd fix the known bugs, and yield better efficiency (because we'd not > > re-compute HTSV all the time). Then for HEAD go for something that fixes > > pruning more fundamentally. > > I don't know what you mean about the patch recomputing HTSV all the > time. The patch doesn't do that. That was in comparison to HEAD, not your patch. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: