On Tue, Jul 29, 2025 at 2:43 AM Doruk Yilmaz <do...@mixrank.com> wrote: > > On Mon, Mar 3, 2025 at 6:39 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > 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? > > Wouldn't mentioning/describing needing to follow the commit order > principle on the documentation be enough for this? > It is quite an advanced feature that I don't believe person intending > to use it won't start with reading documentation first. >
That is true but I still feel there has to be some mechanism where we can catch and give an ERROR to the user, if it doesn't follow the same. For example, pg_replication_origin_advance() always allows going backwards in terms of LSN which means if one doesn't follow commit order, it can lead to breaking the replication as after restart the client can ask to start replication from some prior point. > > Is there any updates on the commit? > I think we are still under discussion about the requirements and design for this API. Can you tell us the use case? Did you also intend to use it for parallel apply, if so, can you also tell at a high level, how you are planning to manage origin? It will help us to extend the API(s) in a meaningful way. -- With Regards, Amit Kapila.
