From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Improving the latch handling between logical replication launcher and worker processes. |
Date: | 2024-07-04 11:22:06 |
Message-ID: | 8acec4af-f616-49bd-8203-eb29bf85130a@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-07-04 11:30:17 | Re: Pluggable cumulative statistics |
Previous Message | Aleksei Fakeev | 2024-07-04 11:16:07 | RE: Test_extensions installcheck fails with ICU provider, workaround |