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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7)
Дата
Msg-id CAPpHfduEXg9GHACU7hPef+KwELfQu2yUSoxoGRrK2CuuuY9QXA@mail.gmail.com
обсуждение исходный текст
Ответ на 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)
Список pgsql-hackers
On Mon, Sep 30, 2019 at 10:54 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Sun, Sep 29, 2019 at 8:12 AM Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
> > I just managed to reproduce this using two sessions on master branch.
> >
> > session 1
> >     session 2
>
> Was the involvement of the pending list stuff in Chen's example just a
> coincidence? Can you recreate the problem while eliminating that
> factor (i.e. while setting fastupdate to off)?
>
> Chen's example involved an INSERT that deadlocked against VACUUM --
> not a SELECT. Is this just a coincidence?

Chen wrote.

> Unfortunately the insert process(run by gcore) held no lwlock, it should be another process(we did not fetch core
file)that hold the lwlock needed for autovacuum process.
 

So, he catched backtrace for INSERT and post it for information.  But
since INSERT has no lwlocks held, it couldn't participate deadlock.
It was just side waiter.

I've rerun my reproduction case and it still deadlocks.  Just the same
steps but GIN index with (fastupdate = off).

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Hooks for session start and end, take two