From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: TopoSort() fix
In-reply-to: 
 <CA+TgmoaUQ+XvS+3U3GBsprSqUq1PBXk2RU_cbSopj2q+GFO=Lw@mail.gmail.com>
References: 
 <CAEri+mKtZkj=+phnkkD9_8sf1fLFUqwHio8Ls4f7JGVgqku6QQ@mail.gmail.com>
 <20190726220538.GA17809@alvherre.pgsql>
 <20190726234835.xqyfukqhhzdiqoih@alap3.anarazel.de>
 <17997.1564187056@sss.pgh.pa.us> <20190729015059.GE6959@paquier.xyz>
 <23797.1564412165@sss.pgh.pa.us>
 <CA+Tgmob7Hj9kDcULJUPv7mNw9KwXpVkwe9TXw_fxQrDWWbb_sA@mail.gmail.com>
 <3243.1564437314@sss.pgh.pa.us>
 <CA+TgmoaUQ+XvS+3U3GBsprSqUq1PBXk2RU_cbSopj2q+GFO=Lw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 29 Jul 2019 20:57:15 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13214.1564451308.1@sss.pgh.pa.us>
Date: Mon, 29 Jul 2019 21:48:28 -0400
Message-ID: <13215.1564451308@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 29, 2019 at 5:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> FYI, I just got done inventing a way to reach that code, and I have
>> to suspect that it's impossible to do so in production, because under
>> ordinary circumstances no parallel worker will take any exclusive lock
>> that isn't already held by its leader.  (If you happen to know an
>> easy counterexample, let's see it.)

> I think the way you could make that happen would be to run a parallel
> query that calls a user-defined function which does LOCK TABLE.

I tried that first.  There are backstops preventing doing LOCK TABLE
in a worker, just like for advisory locks.

I believe the only accessible route to taking any sort of new lock
in a parallel worker is catalog lookups causing AccessShareLock on
a catalog.  In principle, maybe you could make a deadlock situation
by combining parallel workers with something that takes
AccessExclusiveLock on a catalog ... but making that into a reliable
test case sounds about impossible, because AEL on a catalog will
have all sorts of unpleasant side-effects, such as blocking
isolationtester's own queries.  (Getting it to work in a
CLOBBER_CACHE_ALWAYS build seems right out, for instance.)

			regards, tom lane