Re: Deadlock between logrep apply worker and tablesync worker
От | Amit Kapila |
---|---|
Тема | Re: Deadlock between logrep apply worker and tablesync worker |
Дата | |
Msg-id | CAA4eK1JVVjO3yybAErEc4Xtc-HFaZfZwB9TOw1-YjSgOskDHcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Deadlock between logrep apply worker and tablesync worker (vignesh C <vignesh21@gmail.com>) |
Ответы |
RE: Deadlock between logrep apply worker and tablesync worker
|
Список | pgsql-hackers |
On Mon, Jan 30, 2023 at 9:20 AM vignesh C <vignesh21@gmail.com> wrote: > > On Sat, 28 Jan 2023 at 11:26, Amit Kapila <amit.kapila16@gmail.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.
В списке pgsql-hackers по дате отправления: