pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed 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 14:10:13 -0400
Message-ID: <28979.1564510213@sss.pgh.pa.us> (raw )
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 >
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
view thread (27+ messages) latest in thread
Message-ID: <28979.1564510213@sss.pgh.pa.us>
Permalink: ../28979.1564510213@sss.pgh.pa.us/
Also on: postgresql.org/message-id/28979.1564510213@sss.pgh.pa.us
copy link · copy postgr.es
reply 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: <28979.1564510213@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