Justin Pryzby <pry...@telsasoft.com> writes:
> Running pg10.2, I have a handful of maintenance jobs run in the middle of the
> night, which appear to have gotten stuck waiting on each other..
> ts=# SELECT granted, pid, mode, virtualtransaction, virtualxid FROM pg_locks
> WHERE virtualxid='22/4317099' ORDER BY 1,2,3;
> granted | pid | mode | virtualtransaction | virtualxid
> ---------+-------+---------------+--------------------+------------
> f | 20488 | ShareLock | 19/28401734 | 22/4317099
> t | 6471 | ExclusiveLock | 22/4317099 | 22/4317099
PID 20488 is evidently waiting for PID 6471 to finish its transaction.
What's that one doing?
> Is it a bug that this isn't caught by a deadlock detector and cancelled?
We did find a bug recently with concurrent CREATE INDEX CONCURRENTLY's
all waiting for each other to commit.
regards, tom lane
