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
