Re: TopoSort() fix

On Tue, Jul 30, 2019 at 2:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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