Re: [Patch] add new parameter to pg_replication_origin_session_setup

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Doruk Yilmaz <doruk(at)mixrank(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date: 2025-08-12 09:27:49
Message-ID: CAA4eK1+NDjprcKvr0p2GDMTCs9yxFCY41bOd+6avqAm2n+TXdQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 11, 2025 at 10:41 PM Doruk Yilmaz <doruk(at)mixrank(dot)com> wrote:
>
> On Mon, Aug 11, 2025 at 9:44 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > How do you advance the origin? Did you use > pg_replication_origin_advance()? If so, you should be aware that it
> > can be used for initial setup; see comment in that API code...
>
> No, we don't use pg_replication_origin_advance(). We use
> pg_replication_origin_xact_setup() instead as I mentioned before.
>
> Each worker does the following:
> 1. Sets up its own replication-origin session with
> pg_replication_origin_session_setup() (using the master process PID).
> 2. Applies changes inside transactions.
> 3. Right before commit, calls pg_replication_origin_xact_setup(lsn,
> commit_timestamp).
> 4. Commits only if everything succeeded, so the origin only advances
> on a real commit.
>
> That way, the origin LSN moves forward only when the transaction is
> actually committed. If something fails or the process crashes, the
> origin stays at the last successful commit, and on restart we replay
> from the correct spot. It's safer than advancing the origin without
> knowing the transaction made it to disk.
>

Your use looks good to me. So, maybe we can update the docs with the
dangers if the users of API doesn't follow commit order then it may
lead to data inconsistency should be sufficient. Additionally, we may
want to give an example as to how to use this API for parallel apply.

Thoughts?

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2025-08-12 09:32:07 RE: Conflict detection for update_deleted in logical replication
Previous Message Japin Li 2025-08-12 09:25:30 Re: Excessive LOG messages from replication slot sync worker