From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: TopoSort() fix
Date: Tue, 30 Jul 2019 10:27:24 -0400
Message-ID: <11847.1564496844@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, michael@paquier.xyz, andres@anarazel.de, alvherre@2ndquadrant.com
Subject: Re: TopoSort() fix
In-Reply-To: <11847.1564496844@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox