Re: [Patch] add new parameter to pg_replication_origin_session_setup

Doruk Yilmaz <doruk@mixrank.com>

From: Doruk Yilmaz <doruk@mixrank.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: pgsql-hackers@lists.postgresql.org, Amit Kapila <amit.kapila16@gmail.com>
Date: 2025-09-03T12:43:25Z
Lists: pgsql-hackers
Dear Hayato,

> So, your python process establishes two connections, for publisher (replication connection)
> and subscriber (normal connection). It receives changes from the publisher,
> constructs SQL statements from the received results, and sends to subscriber's
> backend, is it right?

Actually, it's a bit simpler than that - there are no two connections.
Our program reads changes from JSONL files rather than directly from a
publisher connection.
We have multiple Python processes, each with a single database
connection to the subscriber,
reading from these files and applying changes in parallel.

> Is there a rule which attribute is clarified and others are not?
> For example, VOLATILE is specified on both side, STRICT is written only in the
> system_functions.sql, and PARALLEL UNSAFE is set on pg_proc.dat.

In pg_proc.dat, I believe the STRICT, IMMUTABLE, and PARALLEL SAFE are
the defaults (check out pg_proc.h).
So in pg_proc.dat, the ones that are specified are the ones that
aren't defaults,
there is provolatile => 'v' (for VOLATILE) and proparallel => 'u' (for
UNSAFE), but no prostrict since it's already true by default.
In system_functions.sql, I went with being explicit about all the
attributes for clarity as it is the code declaration.
If you want, I can also make the pg_proc.dat explicit.

Thanks,
Doruk Yılmaz



Commits

  1. Refactor replorigin_session_setup() for better readability.

  2. Prevent unintended dropping of active replication origins.

  3. Add optional pid parameter to pg_replication_origin_session_setup().