Re: [Patch] add new parameter to pg_replication_origin_session_setup

From: Doruk Yilmaz <doruk(at)mixrank(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(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-11 17:11:34
Message-ID: CAMPB6wckvkKrXVPH5j8Ske2cVedkb-TRLdnOb5e74zYM1CynGw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

So the issue you described is not relevant for our implementation.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2025-08-11 17:54:38 Re: Adding locks statistics
Previous Message Jingtang Zhang 2025-08-11 17:05:26 Re: Possible inaccurate description of wal_compression in docs