Re: Deadlock in multiple CIC.

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

In response to

Responses

Browse pgsql-hackers by date

  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++