diff options
author | Amit Kapila <akapila@postgresql.org> | 2025-09-19 05:38:40 +0000 |
---|---|---|
committer | Amit Kapila <akapila@postgresql.org> | 2025-09-19 05:38:40 +0000 |
commit | 5b148706c5c8ffffe5662fe569a0f0bcef2351d9 (patch) | |
tree | 957ed0d501fbbff5c70382f1f98819b9be6608f9 /doc/src | |
parent | 8aac5923a3611aa89998368a09c54892b93ebdd9 (diff) |
Add optional pid parameter to pg_replication_origin_session_setup().
Commit 216a784829c introduced parallel apply workers, allowing multiple
processes to share a replication origin. To support this,
replorigin_session_setup() was extended to accept a pid argument
identifying the process using the origin.
This commit exposes that capability through the SQL interface function
pg_replication_origin_session_setup() by adding an optional pid parameter.
This enables multiple processes to coordinate replication using the same
origin when using SQL-level replication functions.
This change allows the non-builtin logical replication solutions to
implement parallel apply for large transactions.
Additionally, an existing internal error was made user-facing, as it can
now be triggered via the exposed SQL API.
Author: Doruk Yilmaz <doruk@mixrank.com>
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Euler Taveira <euler@eulerto.com>
Discussion: https://postgr.es/m/CAMPB6wfe4zLjJL8jiZV5kjjpwBM2=rTRme0UCL7Ra4L8MTVdOg@mail.gmail.com
Discussion: https://postgr.es/m/CAE2gYzyTSNvHY1+iWUwykaLETSuAZsCWyryokjP6rG46ZvRgQA@mail.gmail.com
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/func/func-admin.sgml | 23 |
1 files changed, 21 insertions, 2 deletions
diff --git a/doc/src/sgml/func/func-admin.sgml b/doc/src/sgml/func/func-admin.sgml index 57ff333159f..1b465bc8ba7 100644 --- a/doc/src/sgml/func/func-admin.sgml +++ b/doc/src/sgml/func/func-admin.sgml @@ -1315,7 +1315,7 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset <indexterm> <primary>pg_replication_origin_session_setup</primary> </indexterm> - <function>pg_replication_origin_session_setup</function> ( <parameter>node_name</parameter> <type>text</type> ) + <function>pg_replication_origin_session_setup</function> ( <parameter>node_name</parameter> <type>text</type> <optional>, <parameter>pid</parameter> <type>integer</type> <literal>DEFAULT</literal> <literal>0</literal></optional> ) <returnvalue>void</returnvalue> </para> <para> @@ -1323,7 +1323,26 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset origin, allowing replay progress to be tracked. Can only be used if no origin is currently selected. Use <function>pg_replication_origin_session_reset</function> to undo. - </para></entry> + If multiple processes can safely use the same replication origin (for + example, parallel apply processes), the optional <parameter>pid</parameter> + parameter can be used to specify the process ID of the first process. + The first process must provide <parameter>pid</parameter> equals to + <literal>0</literal> and the other processes that share the same + replication origin should provide the process ID of the first process. + </para> + <caution> + <para> + When multiple processes share the same replication origin, it is critical + to maintain commit order to prevent data inconsistency. While processes + may send operations out of order, they must commit transactions in the + correct sequence to ensure proper replication consistency. The recommended workflow + for each worker is: set up the replication origin session with the first process's PID, + apply changes within transactions, call <function>pg_replication_origin_xact_setup</function> + with the LSN and commit timestamp before committing, then commit the + transaction only if everything succeeded. + </para> + </caution> + </entry> </row> <row> |