From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jeremy Finzel <finzelj(at)gmail(dot)com> |
Subject: | Re: Deadlock in multiple CIC. |
Date: | 2017-12-26 16:31:03 |
Message-ID: | 20171226163103.uzs7oq2fsvo3ugtw@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Arthur Zakirov | 2017-12-26 16:48:27 | [PROPOSAL] Shared Ispell dictionaries |
Previous Message | Peter Eisentraut | 2017-12-26 15:51:25 | Re: [HACKERS] static assertions in C++ |