On Tue, Jul 29, 2025 at 2:43 AM Doruk Yilmaz <doruk@mixrank.com> wrote:
>
> On Mon, Mar 3, 2025 at 6:39 AM Amit Kapila <amit.kapila16@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.
