Re: Improving the latch handling between logical replication launcher and worker processes. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Improving the latch handling between logical replication launcher and worker processes.
Date
Msg-id 8acec4af-f616-49bd-8203-eb29bf85130a@iki.fi
Whole thread Raw
In response to Re: Improving the latch handling between logical replication launcher and worker processes.  (vignesh C <vignesh21@gmail.com>)
Responses Re: Improving the latch handling between logical replication launcher and worker processes.
List 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 by date:

Previous
From: Aleksei Fakeev
Date:
Subject: RE: Test_extensions installcheck fails with ICU provider, workaround
Next
From: Bertrand Drouvot
Date:
Subject: Re: Pluggable cumulative statistics