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 CAA4eK1+h4mOvRqRaGfUtSgZuBhzWWmrBcY3jQ4DDV=cEJ4dwnQ@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] add new parameter to pg_replication_origin_session_setup  (shveta malik <shveta.malik@gmail.com>)
Responses RE: [Patch] add new parameter to pg_replication_origin_session_setup
List pgsql-hackers
On Mon, Jan 12, 2026 at 11:31 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> Please find a few comments:
>
> 1)
> + /*
> + * The replication origin cannot be reset if the replication origin is
> + * firstly acquired by this backend and other processes are actively using
> + * now. This can cause acquired_by to be zero and active replication origin
> + * might be dropped.
> + */
> + if (session_replication_state->acquired_by == MyProcPid &&
> + session_replication_state->refcount > 1)
> + ereport(ERROR,
> + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> + errmsg_plural("another process is acquiring the replication origin",
> +    "other processes are acquiring the replication origin",
> +
>
> Since user is not aware of internal acquired_by logic, the error might
> not make much sense to him as to why one session is able to reset
> while another is not. Shall we make it:
>
> ERROR:  cannot reset replication origin "origin_name" while it is
> still shared by other processes
> DETAIL:  the current session is the first process for this replication
> origin, and other processes are sharing it.
> HINT:  ensure this replication origin is reset in all other processes first.
>

How about a slightly tweaked version of these messages:
ERROR: cannot reset replication origin "origin_name" because it is
still in use by other processes
DETAIL: This session is the first process for this replication origin,
and other processes are currently sharing it.
HINT: Reset the replication origin in all other processes before retrying.

> 2)
> When the first session leaves, while the second session is still using
> origin, the third session is able to drop the origin which is not
> right.
> I think replorigin_state_clear() needs a change.
> 'if (state->acquired_by != 0)' check should be replaced by 'if
> (state->refcount > 0)'
>
> Patch 001 had correct changes in replorigin_state_clear(), IMO we
> still need those
>
> 3)
> When first session leaves, while second session is still using origin,
> now correctly third session is not able to join it. It gives error:
> postgres=# SELECT pg_replication_origin_session_setup('origin');
> ERROR: replication origin with ID 1 is already active for another process
>
> Error is not very informative provided the fact that now sharing is
> allowed. Shall it be:
>

Yeah, sharing is allowed but only when used in parallel context by
passing PID. I think a slightly modified version of the above message
such as: "replication origin with ID 1 is already active in another
process" should be sufficient.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Henson Choi
Date:
Subject: Re: Row pattern recognition
Next
From: Chao Li
Date:
Subject: Re: ALTER TABLE: warn when actions do not recurse to partitions