Re: PANIC: wrong buffer passed to visibilitymap_clear
От | Peter Geoghegan |
---|---|
Тема | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Дата | |
Msg-id | CAH2-Wz=_u6ObPqg1Ar638U2CB6thvuni=StjLQ7iniuKX9YZdA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PANIC: wrong buffer passed to visibilitymap_clear (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PANIC: wrong buffer passed to visibilitymap_clear
|
Список | pgsql-hackers |
On Sun, Apr 11, 2021 at 10:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alternatively, we could do what you suggested and redefine things > so that one is only allowed to set the all-visible bit while holding > superexclusive lock; which again would allow an enormous simplification > in heap_update and cohorts. Great detective work. I would rather not go back to requiring a superexclusive lock in vacuumlazy.c (outside of pruning), actually -- I was only pointing out that that had changed, and was likely to be relevant. It wasn't a real proposal. I think that it would be hard to justify requiring a super-exclusive lock just to call PageSetAllVisible(). PD_ALL_VISIBLE is fundamentally redundant information, so somehow it feels like the wrong design. > Either way, it's hard to argue that > heap_update hasn't crossed the complexity threshold where it's > impossible to maintain safely. We need to simplify it. It is way too complicated. I don't think that I quite understand your first proposal right now, so I'll need to go think about it. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: