MIME-Version: 1.0
References: 
 <CAMPB6wfe4zLjJL8jiZV5kjjpwBM2=rTRme0UCL7Ra4L8MTVdOg@mail.gmail.com>
 <b9666b93-093b-4c9f-a385-772d6ab5688c@app.fastmail.com>
 <CAMPB6we7+97L72Ru0=WxMDi24xMbZgr2B8Nwoo5i=r=UNuG_gQ@mail.gmail.com>
 <a4ee2198-5309-4b6f-90ef-c08b45a2f572@app.fastmail.com>
 <CAA4eK1JfPPFTmz7mUk26zPH8+qH9UBpkquxw75x7Ngx_D_6XXQ@mail.gmail.com>
 <CAMPB6wfgvWjSvKNPoJkRqaL46geRDoL++Pt_3Czc2QNAdpVQHw@mail.gmail.com>
 <CAA4eK1JC6yB6q52qEZ5dLNWRUEZoO-aa_XKBZ3_mcb=V2z7zug@mail.gmail.com>
 <CAMPB6weUqU6P2w5VUGVSLKWcvU1AQHmW+7O9qc9yD4CB5kEYVA@mail.gmail.com>
 <CAA4eK1Lm_W5j3DPj6PDSTyodGu87QgxpNwwsi-wVR0+B1FSOoA@mail.gmail.com>
 <CAMPB6wckvkKrXVPH5j8Ske2cVedkb-TRLdnOb5e74zYM1CynGw@mail.gmail.com>
In-Reply-To: 
 <CAMPB6wckvkKrXVPH5j8Ske2cVedkb-TRLdnOb5e74zYM1CynGw@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 12 Aug 2025 14:57:49 +0530
Message-ID: 
 <CAA4eK1+NDjprcKvr0p2GDMTCs9yxFCY41bOd+6avqAm2n+TXdQ@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: Doruk Yilmaz <doruk@mixrank.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1%2BNDjprcKvr0p2GDMTCs9yxFCY41bOd%2B6avqAm2n%2BTXdQ%40mail.gmail.com>
Precedence: bulk

On Mon, Aug 11, 2025 at 10:41=E2=80=AFPM Doruk Yilmaz <doruk@mixrank.com> w=
rote:
>
> On Mon, Aug 11, 2025 at 9:44=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> > How do you advance the origin? Did you use > pg_replication_origin_adva=
nce()? 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?

--=20
With Regards,
Amit Kapila.