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
Date: 2019-03-10 16:40:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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.

Attachment Content-Type Size
0002-Delete-pages-during-GiST-VACUUM.patch application/octet-stream 20.2 KB
0001-Add-block-set-data-structure.patch application/octet-stream 16.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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