From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | vignesh C <vignesh21(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 12:15:57 |
Message-ID: | CAA4eK1JjJWhsSLcyAATV7Fu5GnYFHhNmH=+4y5HqR5vzzbyAUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 27, 2023 at 3:45 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> 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.
>
There is a code in the function replorigin_drop_guts() that uses the
functionality introduced by replorigin_exists(). Can we reuse this
function for the same?
Also, it would be good if you can share the numbers for different runs
of "src/test/subscription/t/002_types.pl" before and after the patch.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Nitin Jadhav | 2023-01-27 12:56:28 | Add a test case related to the error "cannot fetch toast data without an active snapshot" |
Previous Message | Drouvot, Bertrand | 2023-01-27 12:09:16 | Re: Minimal logical decoding on standbys |