RFC: Deadlock detector hooks for victim selection and edge injection
Hi folks
Now that we're well on track for streaming logical decoding, it's becoming
more practical to look at parallel logical apply.
The support for this in pglogical3 benefits from a deadlock detector hook.
It was added in the optional patched postgres pglogical can use to enable
various extra features that weren't possible without core changes, but
isn't present in community postgres yet.
I'd like to add it.
The main benefit is that it lets the logical replication support tell the
deadlock detector that it should prefer to kill the victim whose txn has a
higher upstream commit lsn. That helps encourage parallel logical apply to
make progress in the face of deadlocks between concurrent txns.
Any in-principle objections?
On Mon, Dec 7, 2020 at 9:25 AM Craig Ringer
<craig.ringer@enterprisedb.com> wrote:
Hi folks
Now that we're well on track for streaming logical decoding, it's becoming more practical to look at parallel logical apply.
The support for this in pglogical3 benefits from a deadlock detector hook. It was added in the optional patched postgres pglogical can use to enable various extra features that weren't possible without core changes, but isn't present in community postgres yet.
I'd like to add it.
The main benefit is that it lets the logical replication support tell the deadlock detector that it should prefer to kill the victim whose txn has a higher upstream commit lsn. That helps encourage parallel logical apply to make progress in the face of deadlocks between concurrent txns.
Any in-principle objections?
I think it will depend on your exact proposal of the hook but one
thing we might want to consider is whether it is acceptable to invoke
third-party code after holding LWLocks. We acquire LWLocks in
CheckDeadLock and then run the deadlock detector code.
Also, it might be better if you can expand the use case a bit more. It
is not very clear from what you have written.
--
With Regards,
Amit Kapila.