Horton

Re: TopoSort() fix

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2019-07-30T17:44:17Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 30, 2019 at 1:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In any case, my question at the moment is whether we need the belt-and-
>> suspenders-too approach of having both non-parallel-safe marking and an
>> explicit check inside these functions.  We've largely moved away from
>> hard-wired checks for e.g. superuserness, and surely these things are
>> less dangerous than most formerly-superuser-only functions.

> If we can't think of a way that the lack of these checks could crash
> it, then I think it's OK to remove the hardwired checks.  If we can,
> I'd favor keeping them.

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.

			regards, tom lane

Commits

  1. Add an isolation test to exercise parallel-worker deadlock resolution.

  2. Mark advisory-lock functions as parallel restricted, not parallel unsafe.

  3. Fix busted logic for parallel lock grouping in TopoSort().