Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock(PG10.7)

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, chenhj <chjischj(at)163(dot)com>, 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(PG10.7)
Date: 2019-09-30 05:38:10
Message-ID: AFDDB5CC-CC41-4E73-AD92-09AF4BDE926F@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 29 сент. 2019 г., в 21:27, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> написал(а):
>
> Patch with fix is attached. Idea is simple: ginScanToDelete() now
> keeps exclusive lock on left page eliminating the need to relock it.
> So, we preserve left-to-right locking order and can't deadlock with
> ginStepRight().

In this function ginDeletePage(gvs, blkno, BufferGetBlockNumber(me->leftBuffer),...)
we are going to reread buffer
lBuffer = ReadBufferExtended(gvs->index, MAIN_FORKNUM, leftBlkno,
RBM_NORMAL, gvs->strategy);
Is it OK?

> 30 сент. 2019 г., в 0:52, Peter Geoghegan <pg(at)bowt(dot)ie> написал(а):
>
> Why is it okay
> that there is no nbtree-style distinction between page deletion and
> page recycling?
As far as I understand deleted page is stamped with
GinPageSetDeleteXid(page, ReadNewTransactionId());
It will not be recycled until that Xid is far behind.
BTW we found a small bug (wraparound) in similar GiST and B-tree implementations.
Probably, it's there in GIN too.

--
Andrey Borodin
Open source RDBMS development team leader
Yandex.Cloud

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-09-30 06:06:57 Re: pgbench - allow to create partitioned tables
Previous Message Andrew Gierth 2019-09-30 05:37:48 Re: Possible bug: SQL function parameter in window frame definition