Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7)
От | Andrey Borodin |
---|---|
Тема | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7) |
Дата | |
Msg-id | AFDDB5CC-CC41-4E73-AD92-09AF4BDE926F@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7) (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7)
Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7) |
Список | pgsql-hackers |
> 29 сент. 2019 г., в 21:27, Alexander Korotkov <a.korotkov@postgrespro.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@bowt.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
В списке pgsql-hackers по дате отправления: