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
