Re: TopoSort() fix - Mailing list pgsql-hackers

From Robert Haas
Subject Re: TopoSort() fix
Date
Msg-id CA+TgmoZs+eYHqwnLME2Fk2yR9-BT+H1YKPe1_cv7z1-q17JQyA@mail.gmail.com
Whole thread Raw
In response to Re: TopoSort() fix  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jul 30, 2019 at 2:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Sure, I was basically just asking whether you could foresee any
crash-risk of the proposed change.  It sounds like the answer is "no,"
so I'm fine with it on that basis.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Unused header file inclusion
Next
From: Anastasia Lubennikova
Date:
Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.