Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Andreas Karlsson <andreas@proxel.se>
Date: 2019-10-19T02:41:06Z
Lists: pgsql-hackers 
On Fri, Oct 18, 2019 at 01:26:27PM -0500, Justin Pryzby wrote:
> Checking if anybody is working on either of these
> https://www.postgresql.org/message-id/20191013025145.GC4475%40telsasoft.com
> https://www.postgresql.org/message-id/20191015164047.GA22729%40telsasoft.com

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.
--
Michael

Commits

  1. Fix handling of pg_class.relispartition at swap phase in REINDEX CONCURRENTLY

  2. Handle interrupts within a transaction context in REINDEX CONCURRENTLY