Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held
Дата
Msg-id 20191023101833.GA2109@paquier.xyz
обсуждение исходный текст
Ответ на Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Sat, Oct 19, 2019 at 11:41:06AM +0900, Michael Paquier wrote:
> FWIW, I have spent an hour or two poking at this issue the last couple
> of days so I am not ignoring both, not as much as I would have liked
> but well...  My initial lookup leads me to think that something is
> going wrong with the cleanup of the session-level lock on the parent
> table taken in the first transaction doing the REINDEX CONCURRENTLY.

I can confirm that this is an issue related to session locks which are
not cleaned up when in an out-of-transaction state, state that can be
reached between a transaction commit or start while holding at least
one session lock within one single command of VACUUM, CIC or REINDEX
CONCURRENTLY.  The failure is actually pretty easy to reproduce if you
add an elog(ERROR) after a CommitTransactionCommand() call and then
shut down the connection.  I am starting a new thread about that.  The
problem is larger than it looks, and exists for a long time.
--
Michael

Вложения

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

Предыдущее
От: btendouan
Дата:
Сообщение: Re: pgbench - extend initialization phase control
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions