Re: TopoSort() fix

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