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 |
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 |