Re: RFC: Deadlock detector hooks for victim selection and edge injection - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: RFC: Deadlock detector hooks for victim selection and edge injection
Date
Msg-id CAA4eK1JXcZ_0Koc8KaGcH+JFkb0f55fAzdpimnVk6Y_w+npMaw@mail.gmail.com
Whole thread Raw
In response to RFC: Deadlock detector hooks for victim selection and edge injection  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
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
postgrespglogical can use to enable various extra features that weren't possible without core changes, but isn't
presentin 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
killthe victim whose txn has a higher upstream commit lsn. That helps encourage parallel logical apply to make progress
inthe 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.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: get_constraint_index() and conindid
Next
From: Bharath Rupireddy
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS