Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: "chjischj(at)163(dot)com" <chjischj(at)163(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock
Date: 2018-11-23 10:18:19
Message-ID: 5699F51C-04B6-4140-9F21-3D7A98943F77@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

> 15 нояб. 2018 г., в 17:30, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> написал(а):
>
> I think I can compose patch for consideration.

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

Let's consider concurrent deletion.
As far as I understand, absence of high-key makes unsafe concurrent deletion of highest keys from internal pages. Thus, internal pages cannot be deleted at all.
PFA patch with most simple deletion algorithm:
1. Descend to leftmost leaf
2. Scan by rightlinks until rightmost page
3. Delete empty leaf pages, if they are not highest keys in corresponding parent page

Parent page is found by rightlink scan for leftmost parent with cached previous result.
Deleted page is stamped by ReadNewTransactionId()'s xid, page cannot be reused until deletion xid is beyond RecentGlobalDataXmin.
DeleteXid is WAL-logged.
I've refactored btree->getLeftMostChild() and btree->findChildPtr() to reuse their code (removed unnecessary parameter).

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. In this description of proposed patch I've tried to put concepts in a minimum of words. Please ping me if some concepts sound cryptic and require more clarification.

Best regards, Andrey Borodin.

Attachment Content-Type Size
0001-Use-correct-locking-protocol-during-GIN-posting-tree.patch application/octet-stream 20.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2018-11-23 11:14:32 Re: COPY FROM WHEN condition
Previous Message Thomas Munro 2018-11-23 07:56:56 Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process