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 | 20220311034632.pszcrrhnhtd4myll@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 2022-03-10 19:40:21 -0800, Peter Geoghegan wrote: > On Thu, Mar 10, 2022 at 7:13 PM Andres Freund <andres@anarazel.de> wrote: > > > 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. I'm not talking about just moving the vistest acquisition, but also vacuum_set_xid_limits(). Which obviously *does* benefit from delaying as long as possible. > > 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. Cool. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: