Horton

Re: TopoSort() fix

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-30T02:06:09Z
Lists: pgsql-hackers 
On Mon, Jul 29, 2019 at 9:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I tried that first.  There are backstops preventing doing LOCK TABLE
> in a worker, just like for advisory locks.
>
> 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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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().