Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held
Date
Msg-id 20191023101833.GA2109@paquier.xyz
Whole thread Raw
In response to Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held  (Michael Paquier <michael@paquier.xyz>)
Responses Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock onobject 14185/39327/0 is already held
List 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

Attachment

pgsql-hackers by date:

Previous
From: btendouan
Date:
Subject: Re: pgbench - extend initialization phase control
Next
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions