| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Doruk Yilmaz <doruk(at)mixrank(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [Patch] add new parameter to pg_replication_origin_session_setup |
| Date: | 2026-01-13 02:56:54 |
| Message-ID: | CAA4eK1+h4mOvRqRaGfUtSgZuBhzWWmrBcY3jQ4DDV=cEJ4dwnQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 12, 2026 at 11:31 AM shveta malik <shveta(dot)malik(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-01-13 03:18:58 | Re: ALTER TABLE: warn when actions do not recurse to partitions |
| Previous Message | Henson Choi | 2026-01-13 02:53:22 | Re: Row pattern recognition |