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-Wzn5i1qQJWUU5XjnmWMRJtVEgoVMapWtoDpyU+dXo9F_pw@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 Thu, Mar 10, 2022 at 7:13 PM Andres Freund <andres@anarazel.de> wrote: > > NB: I intend to commit this revision of the patch (or something pretty > > close to it) in the next few days, barring any objections. > > WFM. Cool. > > On Wed, Mar 9, 2022 at 4:25 PM Andres Freund <andres@anarazel.de> wrote: > > > I think it'd be nicer if we did the horizon determination after allocating > > > space for dead tuples... But it's still better than today, so... > > > > Why would it be nicer? > > Large allocation can take a bit. Especially dead_item_alloc() sneakily > initializes parallelism (which is darn ugly). Determining the horizon after > doing expensive stuff gives you a slightly better horizon... I'm confused. You recently said "I don't think the minor optimization [delaying establishing vistest] does anything (which I had stated wrongly at some point in this thread)". But you now seem to be saying that delaying establishing vistest has at least some small value as an optimization. At least in theory. > The whole s/nblocks/rel_pages/ seems like it should be done separately. I'll break the mechanical s/nblocks/rel_pages/ out into a dedicated commit, then. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: