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

On Sat, Oct 12, 2019 at 09:51:45PM -0500, Justin Pryzby wrote:
> 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.

I got an assertion failure on that:
(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f417a283535 in __GI_abort () at abort.c:79
#2 0x0000564c351f0f4f in ExceptionalCondition
(conditionName=0x564c353d0ac8
"SHMQueueEmpty(&(MyProc->myProcLocks[i]))", errorType=0x564c353d09de
"FailedAssertion",
fileName=0x564c353d09d7 "proc.c", lineNumber=832) at assert.c:54
#3 0x0000564c3504debe in ProcKill (code=0, arg=0) at proc.c:832
#4 0x0000564c3503430e in shmem_exit (code=0) at ipc.c:272
#5 0x0000564c3503413d in proc_exit_prepare (code=0) at ipc.c:194
#6 0x0000564c3503409c in proc_exit (code=0) at ipc.c:107
#7 0x0000564c3506a629 in PostgresMain (argc=1,
argv=0x564c35c12ae0, dbname=0x564c35c129d0 "ioltas",
username=0x564c35c129b0 "ioltas") at postgres.c:4464
#8 0x0000564c34fb94ed in BackendRun (port=0x564c35c0c6b0) at
postmaster.c:4465
#9 0x0000564c34fb8c59 in BackendStartup (port=0x564c35c0c6b0) at
postmaster.c:4156
#10 0x0000564c34fb4c7f in ServerLoop () at postmaster.c:1718
#11 0x0000564c34fb44ad in PostmasterMain (argc=3,
argv=0x564c35bdefd0) at postmaster.c:1391
#12 0x0000564c34ec0d3d in main (argc=3, argv=0x564c35bdefd0) at main.c:210

This means that all the locks hold have not actually been released
when the timeout has kicked in. Not sure that this is only an issue
related to REINDEX CONCURRENTLY, but if that's the case then we are
missing a cleanup step.
--
Michael