|From:||Andrey Borodin <x4mmm(at)yandex-team(dot)ru>|
|To:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru>|
|Subject:||Re: GiST VACUUM|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 5 марта 2019 г., в 18:21, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> написал(а):
> On 05/03/2019 02:26, Andrey Borodin wrote:
>> That's cool! I'll work on 2nd step of these patchset to make
>> blockset data structure prettier and less hacky.
> Committed the first patch. Thanks for the patch!
That's cool! Thanks!
> I'll change the status of this patch to "Waiting on Author", to reflect the state of the 2nd patch, since you're working on the radix tree blockset stuff.
Here's new version of the patch for actual page deletion.
1. Fixed possible concurrency issue:
We were locking child page while holding lock on internal page. Notes in GiST README recommend locking child before parent.
Thus now we unlock internal page before locking children for deletion, and lock it again, check that everything is still on it's place and delete only then.
One thing still bothers me. Let's assume that we have internal page with 2 deletable leaves. We lock these leaves in order of items on internal page. Is it possible that 2nd page have follow-right link on 1st and someone will lock 2nd page, try to lock 1st and deadlock with VACUUM?
2. Added radix-tree-based block set to lib, with tests.
Best regards, Andrey Borodin.
|Next Message||Andrey Borodin||2019-03-10 16:42:12||Re: Covering GiST indexes|
|Previous Message||Pavel Stehule||2019-03-10 16:39:42||Re: proposal: plpgsql pragma statement|