Re: Improving the latch handling between logical replication launcher and worker processes.

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Improving the latch handling between logical replication launcher and worker processes.
Дата
Msg-id 8acec4af-f616-49bd-8203-eb29bf85130a@iki.fi
обсуждение исходный текст
Ответ на Re: Improving the latch handling between logical replication launcher and worker processes.  (vignesh C <vignesh21@gmail.com>)
Ответы Re: Improving the latch handling between logical replication launcher and worker processes.
Список pgsql-hackers
I'm don't quite understand the problem we're trying to fix:

> Currently the launcher's latch is used for the following: a) worker
> process attach b) worker process exit and c) subscription creation.
> Since this same latch is used for multiple cases, the launcher process
> is not able to handle concurrent scenarios like: a) Launcher started a
> new apply worker and waiting for apply worker to attach and b) create
> subscription sub2 sending launcher wake up signal. In this scenario,
> both of them will set latch of the launcher process, the launcher
> process is not able to identify that both operations have occurred 1)
> worker is attached 2) subscription is created and apply worker should
> be started. As a result the apply worker does not get started for the
> new subscription created immediately and gets started after the
> timeout of 180 seconds.

I don't see how we could miss a notification. Yes, both events will set 
the same latch. Why is that a problem? The loop will see that the new 
worker has attached, and that the new subscription has been created, and 
process both events. Right?

-- 
Heikki Linnakangas
Neon (https://neon.tech)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksei Fakeev
Дата:
Сообщение: RE: Test_extensions installcheck fails with ICU provider, workaround
Следующее
От: Bertrand Drouvot
Дата:
Сообщение: Re: Pluggable cumulative statistics