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+TgmobX+8Hj9Q-yREEqZGDjeMLAvKoSPt8jEs6Tc55VjVxgsg@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>
 <13215.1564451308@sss.pgh.pa.us>
 <CA+TgmobX+8Hj9Q-yREEqZGDjeMLAvKoSPt8jEs6Tc55VjVxgsg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 29 Jul 2019 22:06:09 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11846.1564496844.1@sss.pgh.pa.us>
Date: Tue, 30 Jul 2019 10:27:24 -0400
Message-ID: <11847.1564496844@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 29, 2019 at 9:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Can't the worker just query a previously-untouched table, maybe by
> constructing a string and then using EXECUTE to execute it?

Hm, yeah, looks like you could get a new AccessShareLock that way too.
But not any exclusive lock.

I also looked into whether one could use SELECT FOR UPDATE/SHARE to get
stronger locks at a tuple level, but that's been blocked off as well.
You guys really did a pretty good job of locking that down.

After thinking about this for awhile, though, I believe it might be
reasonable to just remove PreventAdvisoryLocksInParallelMode()
altogether.  The "parallel unsafe" markings on the advisory-lock
functions seem like adequate protection against somebody running
them in a parallel worker.  If you defeat that by calling them from
a mislabeled-parallel-safe wrapper (as the proposed test case does),
then any negative consequences are on your own head.  AFAICT the
only actual negative consequence is that the locks disappear the
moment the parallel worker exits, so we'd not be opening any large
holes even to people who rip off the safety cover.

(BTW, why aren't these functions just "parallel restricted"?)

			regards, tom lane