Re: [Patch] add new parameter to pg_replication_origin_session_setup - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date
Msg-id CAA4eK1JfPPFTmz7mUk26zPH8+qH9UBpkquxw75x7Ngx_D_6XXQ@mail.gmail.com
Whole thread Raw
In response to [Patch] add new parameter to pg_replication_origin_session_setup  (Doruk Yilmaz <doruk@mixrank.com>)
List pgsql-hackers
On Thu, Jan 9, 2025 at 3:26 AM Euler Taveira <euler@eulerto.com> wrote:
>
> On Thu, Aug 15, 2024, at 5:53 PM, Doruk Yilmaz wrote:
>
> Hello again,
>
> On Tue, Aug 13, 2024 at 12:48 AM Euler Taveira <euler@eulerto.com> wrote:
> > I'm curious about your use case. Is it just because the internal function has a
> > different signature or your tool is capable of apply logical replication changes
> > in parallel using the SQL API?
>
> The latter is correct, it applies logical replication changes in parallel.
> Since multiple connections may commit, we need all of them to be able
> to advance the replication origin.
>

To use replication_origin by multiple processes, one must maintain the
commit order as we do internally by allowing the leader process to
wait for the parallel worker to finish the commit. See comments atop
replorigin_session_setup(). Now, we could expose the pid parameter as
proposed by the patch after documenting the additional requirements,
but I am afraid that users may directly start using the API without
following the commit order principle, which can lead to incorrect
replication. So, isn't it better to do something to avoid the misuse
of this feature before exposing it?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] Add regression tests of ecpg command notice (error / warning)
Next
From: Fujii Masao
Date:
Subject: Re: Change log level for notifying hot standby is waiting non-overflowed snapshot