Jeff Janes wrote: > c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least > not as reliably as before) by dropping its own snapshot before waiting for > all the other ones to go away. > > With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on > different tables in the same database started deadlocking against each > other again quite reliably. > > I think the solution is simply to drop the catalog snapshot as well, as in > the attached.
Thanks for the analysis -- it sounds reasonable to me. However, I'm wondering why you used the *Conditionally() version instead of plain InvalidateCatalogSnapshot(). I think they must have the same effect in practice (the assumption being that you can't run CIC in a transaction that may have other snapshots) but the theory seems simpler when calling the other routine: just do away with the snapshot always, period. This is back-patchable to 9.4, first branch which has MVCC catalog scans. It's strange that this has gone undetected for so long. I wonder if there's an interaction with logical decoding and its historical snapshot stuff here. I pinged Jeremy on the other thread about your fix. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
