| From: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Ajin Cherian <itsajin(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Preserve replication origin OIDs in pg_upgrade |
| Date: | 2026-07-06 06:40:34 |
| Message-ID: | CANhcyEVV5A5qm9g7UVT99NpNqVsuzbzLsoteQ5gYOWvVsZsjCQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> All the above changes are updated in patch v10.
>
I noticed that we can create user defined replication origin even if the
total count of replication origins exceeds the max_active_replication_origins
Example:
postgres=# show max_active_replication_origins;
max_active_replication_origins
--------------------------------
1
postgres=# select * from pg_replication_origin;
roident | roname
---------+----------
1 | pg_16387
postgres=# SELECT pg_replication_origin_create('origin1');
pg_replication_origin_create
------------------------------
2
postgres=# select * from pg_replication_origin;
roident | roname
---------+----------
1 | pg_16387
2 | origin1
postgres=# select * from pg_replication_origin_status;
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+------------
1 | pg_16387 | 0/00000000 | 0/00000000
The documentation for max_active_replication_origins says:
```
Specifies how many replication origins (see
<xref linkend="replication-origins"/>) can be tracked simultaneously,
effectively limiting how many logical replication subscriptions can
be created on the server. Setting it to a lower value than the current
number of tracked replication origins (reflected in
<link linkend="view-pg-replication-origin-status">pg_replication_origin_status</link>)
will prevent the server from starting. It defaults to 10. This parameter
can only be set at server start.
```
Since the user-created replication origin above is not
actively tracked in pg_replication_origin_status, no error is reported.
But with this patch, during pg_upgrade we are checking the
'max_active_replication_origins' against 'old_cluster.nrepl_origins'
+ if (old_cluster.nrepl_origins > max_active_replication_origins)
pg_fatal("\"max_active_replication_origins\" (%d) must be greater
than or equal to the number of "
- "subscriptions (%d) in the old cluster",
- max_active_replication_origins, old_cluster.nsubs);
+ "replication origins (%d) in the old cluster",
+ max_active_replication_origins, old_cluster.nrepl_origins);
Since old_cluster.nrepl_origins counts all replication origins, including
user-created ones that may not be tracked, should this check instead compare
max_active_replication_origins with 'the number of rows in
pg_replication_origin_status in old cluster' (i.e., the number of
tracked replication origins)?
Thanks
Shlok Kyal
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ilmar Yunusov | 2026-07-06 06:47:34 | Re: [RFC PATCH v0 0/7] Add EXPLAIN ANALYZE wait event reporting |
| Previous Message | Peter Eisentraut | 2026-07-06 06:34:27 | Re: [PATCH] Fix null pointer dereference in PG19 |