Related to my other post about deadlock detector hooks for victim selection, I'd like to gauge opinions here about whether it's feasible to inject edges into the deadlock detector's waits-for graph.
Doing so would help with detecting deadlocks relating to shm_mq waits, help with implementing distributed deadlock detection solutions, make it possible to spot deadlocks relating to condition-variable waits, etc.
I'm not sure quite how the implementation would look yet, this is an early RFC and sanity check so I don't invest any work into it if it has no hope of going anywhere.
I expect we'd want to build the graph only when the detector is triggered, rather than proactively maintain such edges, so the code implementing the hook would be responsible for keeping track of whatever state it needs to in order to do so.
When called, it'd append "struct EDGE" s to the deadlock detector's waits-for list.
We'd need to support a node representation other than a LOCK* for struct EDGE, and to abstract edge sorting (TopoSort etc) to allow for other edge types. So it wouldn't be a trivial change to make, hence opening with this RFC.
I expect it'd be fine to require each EDGE* to have a PGPROC and to require the PGPROC for waits-for and waiting-for not be the same proc. Distributed systems that use libpq connections to remote nodes, or anything else, would have to register the local-side PGPROC as the involved waiter or waited-on object, and handle any mapping between the remote object and local resource holder/acquirer themselves, probably using their own shmem state.
Bonus points if the callback could assign weights to the injected edges to bias victim selection more gently. Or a way to tag an waited-for node as not a candidate victim for cancellation.
General thoughts?
