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

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-18 18:26:27
Message-ID: 20191018182627.GI3599@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

On Sat, Oct 12, 2019 at 09:51:45PM -0500, Justin Pryzby wrote:
> I ran into this while trying to trigger the previously-reported segfault.
>
> CREATE TABLE t(i) AS SELECT * FROM generate_series(1,9);
> CREATE INDEX ON t(i);
>
> [pryzbyj(at)database ~]$ for i in `seq 1 9`; do PGOPTIONS='-cstatement_timeout=9' psql postgres --host /tmp --port 5678 -c "REINDEX INDEX CONCURRENTLY t_i_idx" ; done
> ERROR: canceling statement due to statement timeout
> ERROR: lock ShareUpdateExclusiveLock on object 14185/47287/0 is already held
> [...]
>
> Variations on this seem to leave the locks table (?) or something else in a
> Real Bad state, such that I cannot truncate the table or drop it; or at least
> commands are unreasonably delayed for minutes, on this otherwise-empty test
> cluster.

On Tue, Oct 15, 2019 at 11:40:47AM -0500, Justin Pryzby wrote:
> On a badly-overloaded VM, we hit the previously-reported segfault in progress
> reporting. This left around some *ccold indices. I tried to drop them but:
>
> sentinel=# DROP INDEX child.alarms_null_alarm_id_idx1_ccold; -- child.alarms_null_alarm_time_idx_ccold; -- alarms_null_alarm_id_idx_ccold;
> ERROR: could not find tuple for parent of relation 41351896
>
> Those are children of relkind=I index on relkind=p table.
>
> postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i);
> postgres=# CREATE TABLE t1 PARTITION OF t FOR VALUES FROM (1)TO(100);
> postgres=# INSERT INTO t1 SELECT 1 FROM generate_series(1,99999);
> postgres=# CREATE INDEX ON t(i);
>
> postgres=# begin; SELECT * FROM t; -- DO THIS IN ANOTHER SESSION
>
> postgres=# REINDEX INDEX CONCURRENTLY t1_i_idx; -- cancel this one
> ^CCancel request sent
> ERROR: canceling statement due to user request
>
> postgres=# \d t1
> ...
> "t1_i_idx" btree (i)
> "t1_i_idx_ccold" btree (i) INVALID
>
> postgres=# SELECT inhrelid::regclass FROM pg_inherits WHERE inhparent='t_i_idx'::regclass;
> inhrelid
> t1_i_idx
> (1 row)
>
> Not only can't I DROP the _ccold indexes, but also dropping the table doesn't
> cause them to be dropped, and then I can't even slash dee them anymore:
>
> jtp=# DROP INDEX t1_i_idx_ccold;
> ERROR: could not find tuple for parent of relation 290818869
>
> jtp=# DROP TABLE t; -- does not fail, but ..
>
> jtp=# \d t1_i_idx_ccold
> ERROR: cache lookup failed for relation 290818865
>
> jtp=# SELECT indrelid::regclass, * FROM pg_index WHERE indexrelid='t1_i_idx_ccold'::regclass;
> indrelid | 290818865
> indexrelid | 290818869
> indrelid | 290818865
> [...]

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Felder 2019-10-18 19:10:51 Re: jsonb_set() strictness considered harmful to data
Previous Message Ariadne Conill 2019-10-18 17:37:24 jsonb_set() strictness considered harmful to data