Date: Fri, 4 Sep 2020 10:20:33 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Rare deadlock failure in create_am test
Message-ID: <20200904142033.GA8294@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <839004.1599185607@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Sep-03, Tom Lane wrote:

> So it's not hard to understand the problem: DROP of an index AM, cascading
> to an index, will need to acquire lock on the index and then lock on the
> index's table.  Any other operation on the table, like say autovacuum,
> is going to acquire locks in the other direction.

Oh, of course.

> I'm inclined to think that the best fix is to put
> 
> begin;
> lock table [fast_emp4000];
> ...
> commit;
> 
> around the DROP CASCADE.

Yeah, sounds good.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services