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+TgmoY-Ydez0KsCeFe2DTY7EzqKk1+BCH0TySEJ_1YYpraLEw@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>
 <11847.1564496844@sss.pgh.pa.us>
 <CA+TgmobUiYFpdX2=FErkT7gmu9FsL3_CgU35wfRb+WecVMLktw@mail.gmail.com>
 <27546.1564508196@sss.pgh.pa.us>
 <CA+TgmobQwnEwcdigz_QDS+npXejx17OPOvnRSCHw1T9evVQY9g@mail.gmail.com>
 <27870.1564508657@sss.pgh.pa.us>
 <CA+TgmoY-Ydez0KsCeFe2DTY7EzqKk1+BCH0TySEJ_1YYpraLEw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 30 Jul 2019 13:45:42 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28978.1564510213.1@sss.pgh.pa.us>
Date: Tue, 30 Jul 2019 14:10:13 -0400
Message-ID: <28979.1564510213@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 30, 2019 at 1:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, there'd be an actual isolation test that they work ;-), if you
>> override the marking.  Admittedly, one test case does not prove that
>> there's no way to crash the system, but that can be said of most
>> parts of Postgres.

> True.  I'm just talking about what we can foresee.

Sure.  But I think what we can foresee is that if there are any bugs
reachable this way, they'd be reachable and need fixing regardless.
We've already established that parallel workers can take and release locks
that their leader isn't holding.  Apparently, they won't take anything
stronger than RowExclusiveLock; but even AccessShare is enough to let a
process participate in all interesting behaviors of the lock manager,
including blocking, being blocked, and being released early by deadlock
resolution.  And the advisory-lock functions are pretty darn thin wrappers
around the lock manager.  So I'm finding it hard to see where there's
incremental risk, even if a user does intentionally bypass the parallel
safety markings.  And what we get in return is an easier way to add tests
for this area.

			regards, tom lane