Re: [Patch] add new parameter to pg_replication_origin_session_setup
От | Amit Kapila |
---|---|
Тема | Re: [Patch] add new parameter to pg_replication_origin_session_setup |
Дата | |
Msg-id | CAA4eK1JfPPFTmz7mUk26zPH8+qH9UBpkquxw75x7Ngx_D_6XXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [Patch] add new parameter to pg_replication_origin_session_setup (Doruk Yilmaz <doruk@mixrank.com>) |
Список | 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 по дате отправления: