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

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(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-05-29 09:39:54
Message-ID: CALDaNm1d3sJ_9AiZj0KAJE0dQP9NUBtK5hYrSut+fj-b9WpydQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 29 May 2024 at 10:41, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Thu, Apr 25, 2024 at 6:59 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
>
> > c) Don't reset the latch at worker attach and allow launcher main to
> > identify and handle it. For this there is a patch v6-0002 available at
> > [2].
>
> This option c seems the easiest. Can you explain what are the
> drawbacks of using this approach?

This solution will resolve the issue. However, one drawback to
consider is that because we're not resetting the latch, in this
scenario, the launcher process will need to perform an additional
round of acquiring subscription details and determining whether the
worker should start, regardless of any changes in subscriptions.

Regards,
Vignesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-05-29 09:55:52 Re: Ambiguous description on new columns
Previous Message vignesh C 2024-05-29 09:37:56 Re: Improving the latch handling between logical replication launcher and worker processes.