On Fri, Nov 23, 2018 at 2:18 AM Andrey Borodin <x4...@yandex-team.ru> wrote: > I found no practical way to fix concept of "subtree-lock". Pre-locking all > left siblings for cleanup would suffice, but does not look very practical. > GIN Posting tree has no all useful B-tree inventory like left links and high > keys for concurrent deletes without "subtree-lock".
Significantly changing the design of GIN vacuuming in back branches for a release that's more than a year old is absolutely out of the question. I think that your patch should be evaluated as a new v12 feature, following the revert of 218f51584d5. > Please note, that attached patch do not fix 2nd bug found by Chen in page > delete redo. > > I understand that reverting commit 218f51584d5 and returning to long but > finite root locks is safest solution Whatever happens with the master branch, I think that reverting commit 218f51584d5 is the only option on the table for the back branches. Its design is based on ideas on locking protocols that are fundamentally incorrect and unworkable. I don't have a lot of faith in our ability to retrofit a design that fixes the issue without causing problems elsewhere. -- Peter Geoghegan