Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
От | vignesh C |
---|---|
Тема | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |
Дата | |
Msg-id | CALDaNm2RRDdsdf5U+Cc1LJc+DrpZwfX2JEa7NTkboyo2BAN0jA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
|
Список | pgsql-hackers |
On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > > Here's a patchset that uses that approach. Naming of functions, types, > fields and arguments TBD. The patch works and passes the new > VACUUM-conflict tests, though I suspect the SP-GIST tests to have > bugs, as an intermediate version of my 0003 patch didn't trigger the > tests to fail, even though it did not hold a pin on (all) sorted > items' data when it was being checked for visibility and/or returned > from the scan. > > Patch 0001 details the important changes, while 0002/0003 use this new > API to make GIST and SP-GIST's IOS work correctly when concurrent > VACUUM is/was running. > 0004 is the existing patch with tests (v8-0001). I noticed that Mikhail's feedback from [1] is not yet addressed. I have changed the status of the commitfest entry to Waiting on Author, kindly address them and update the status to Needs review. [1] - https://www.postgresql.org/message-id/CANtu0ojz0apXnVia0reTL28eL2=__ev8aLsiH=1XfD_Z3dnkTw@mail.gmail.com Regards, Vignesh
В списке pgsql-hackers по дате отправления: