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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>
Subject: Re: v12.0: reindex CONCURRENTLY: lock ShareUpdateExclusiveLock on object 14185/39327/0 is already held
Date: 2019-10-19 02:41:06
Message-ID: 20191019024106.GE1542@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2019-10-19 03:27:18 pgsql: For all ppc compilers, implement compare_exchange and fetch_add
Previous Message Michael Paquier 2019-10-19 02:34:03 Re: Backport "WITH ... AS MATERIALIZED" syntax to <12?