Re: [Patch] add new parameter to pg_replication_origin_session_setup - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date
Msg-id CAA4eK1LeyzuiRPZB+o7mO0pB6_=tpkjoum5Hj+t1SYydS4K2kQ@mail.gmail.com
Whole thread Raw
In response to RE: [Patch] add new parameter to pg_replication_origin_session_setup  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: [Patch] add new parameter to pg_replication_origin_session_setup
List pgsql-hackers
On Thu, Sep 18, 2025 at 1:07 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear hackers,
>
> > I considered a test, please see attached files.
>

Few comments:
1. +step "s0_compare" {
+    SELECT s0.lsn < s1.lsn
+    FROM local_lsn_store as s0, local_lsn_store as s1
+    WHERE s0.session = 0 AND s1.session = 1;
+}

This appears to be a bit tricky to compare the values. Doing a
sequential scan won't guarantee the order of rows' appearance. Can't
we somehow get the two rows ordered by session_id and compare their
values?

2.
+ else if (candidate_state->acquired_by != acquired_by)
+ {
+ if (initialized)
+ candidate_state->roident = InvalidRepOriginId;
+
  elog(ERROR, "could not find replication state slot for replication
origin with OID %u which was acquired by %d",
  node, acquired_by);
+ }

This doesn't appear neat. Instead, how about checking this case before
setting current_state as shown in attached. If we do that, we
shouldn't even need new variables like current_state and initialized.
Additionally, as shown in attached, it is better to make this a
user-facing error by using ereport.

3. Merge all patches as I don't see the need to do any backpatch here.

--
With Regards,
Amit Kapila.

Attachment

pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Clear logical slot's 'synced' flag on promotion of standby
Next
From: Etsuro Fujita
Date:
Subject: Re: [BUG] Query with postgres fwd deletes more tuples than it should