Re: RFC: Deadlock detector hooks for victim selection and edge injection

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Deadlock detector hooks for victim selection and edge injection
Date: 2020-12-07 10:12:20
Message-ID: CAA4eK1JXcZ_0Koc8KaGcH+JFkb0f55fAzdpimnVk6Y_w+npMaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 7, 2020 at 9:25 AM Craig Ringer
<craig(dot)ringer(at)enterprisedb(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2020-12-07 10:13:59 Re: Parallel Inserts in CREATE TABLE AS
Previous Message Peter Eisentraut 2020-12-07 10:09:16 get_constraint_index() and conindid