Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
| От | Andres Freund |
|---|---|
| Тема | Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM |
| Дата | |
| Msg-id | 20231115231718.y7l72jk5vxsj6dck@awork3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
|
| Список | pgsql-hackers |
Hi, On 2023-11-15 16:32:48 -0500, Robert Haas wrote: > On Mon, Nov 13, 2023 at 8:26 PM Andres Freund <andres@anarazel.de> wrote: > > I think this undersells the situation a bit. We right now do > > FreeSpaceMapVacuumRange() for 8GB of data (VACUUM_FSM_EVERY_PAGES) in the main > > fork, while holding an exclusive page level lock. > > That sounds fairly horrific? It's decidedly not great, indeed. I couldn't come up with a clear risk of deadlock, but I wouldn't want to bet against there being a deadlock risk. I think the rarity of it does ameliorate the performance issues to some degree. Thoughts on whether to backpatch? It'd probably be at least a bit painful, there have been a lot of changes in the surrounding code in the last 5 years. - Andres
В списке pgsql-hackers по дате отправления: