Re: Deadlock between logrep apply worker and tablesync worker

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Deadlock between logrep apply worker and tablesync worker
Date: 2023-01-27 10:15:04
Message-ID: CALDaNm0m6HDp1hAiwpmT2buw8aHdjnMqGRJzHE=eGPe_YdrJ2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 23 Jan 2023 at 10:52, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> IIRC, this is done to prevent concurrent drops of origin drop say by
> exposed API pg_replication_origin_drop(). See the discussion in [1]
> related to it. If we want we can optimize it so that we can acquire
> the lock on the specific origin as mentioned in comments
> replorigin_drop_by_name() but it was not clear that this operation
> would be frequent enough.

Here is an attached patch to lock the replication origin record using
LockSharedObject instead of locking pg_replication_origin relation in
ExclusiveLock mode. Now tablesync worker will wait only if the
tablesync worker is trying to drop the same replication origin which
has already been dropped by the apply worker, the other tablesync
workers will be able to successfully drop the replication origin
without any wait.

Regards,
Vignesh

Attachment Content-Type Size
0001-Lock-the-replication-origin-record-instead-of-lockin.patch text/x-patch 2.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-01-27 10:58:51 Re: meson oddities
Previous Message shveta malik 2023-01-27 10:11:56 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication