On Thu, Jan 9, 2025 at 3:26 AM Euler Taveira <eu...@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 <eu...@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.
