| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com> |
| Cc: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Deadlock between logrep apply worker and tablesync worker |
| Date: | 2023-01-30 06:31:43 |
| Message-ID: | CAA4eK1JVVjO3yybAErEc4Xtc-HFaZfZwB9TOw1-YjSgOskDHcw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 30, 2023 at 9:20 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Sat, 28 Jan 2023 at 11:26, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > One thing that looks a bit odd is that we will anyway have a similar
> > check in replorigin_drop_guts() which is a static function and called
> > from only one place, so, will it be required to check at both places?
>
> There is a possibility that the initial check to verify if replication
> origin exists in replorigin_drop_by_name was successful but later one
> of either table sync worker or apply worker process might have dropped
> the replication origin,
>
Won't locking on the particular origin prevent concurrent drops? IIUC,
the drop happens after the patch acquires the lock on the origin.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2023-01-30 06:39:12 | Re: SQL/JSON revisited |
| Previous Message | Amit Kapila | 2023-01-30 06:26:33 | Re: Time delayed LR (WAS Re: logical replication restrictions) |