RE: pg_upgrade and logical replication
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'vignesh C' <vignesh21@gmail.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2023-09-12T08:55:50Z
Lists: pgsql-hackers
Attachments
- test.sh (application/octet-stream)
Dear Vignesh,
Thank you for updating the patch! Here are some comments.
Sorry if there are duplicate comments - the thread revived recently so I might
lose my memory.
01. General
Is there a possibility that apply worker on old cluster connects to the
publisher during the upgrade? Regarding the pg_upgrade on publisher, the we
refuse TCP/IP connections from remotes and port number is also changed, so we can
assume that subscriber does not connect to. But IIUC such settings may not affect
to the connection source, so that the apply worker may try to connect to the
publisher. Also, is there any hazards if it happens?
02. Upgrade functions
Two functions - binary_upgrade_create_sub_rel_state and binary_upgrade_sub_replication_origin_advance
should be located at pg_upgrade_support.c. Also, CHECK_IS_BINARY_UPGRADE() macro
can be used.
03. Parameter combinations
IIUC getSubscriptionTables() should be exitted quickly if --no-subscriptions is
specified, whereas binary_upgrade_create_sub_rel_state() is failed.
04. I failed my test
I executed attached script but failed to upgrade:
```
Restoring database schemas in the new cluster
postgres
*failure*
Consult the last few lines of "data_N3/pg_upgrade_output.d/20230912T054546.320/log/pg_upgrade_dump_5.log" for
the probable cause of the failure.
Failure, exiting
```
I checked the log and found that binary_upgrade_create_sub_rel_state() does not
support skipping the fourth argument:
```
pg_restore: from TOC entry 4059; 16384 16387 SUBSCRIPTION TABLE sub sub postgres
pg_restore: error: could not execute query: ERROR: function binary_upgrade_create_sub_rel_state(unknown, integer, unknown) does not exist
LINE 1: SELECT binary_upgrade_create_sub_rel_state('sub', 16384, 'r'...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
Command was: SELECT binary_upgrade_create_sub_rel_state('sub', 16384, 'r');
```
IIUC if we allow to skip arguments, we must define wrappers like pg_copy_logical_replication_slot_*.
Another approach is that pg_dump always dumps srsublsn even if it is NULL.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
Commits
-
pg_upgrade: Retrieve subscription count more efficiently.
- 73de50e13e39 17.0 landed
- 364509a2e7f9 18.0 landed
-
Fix random failure in 004_subscription.
- 677a45c4ae16 17.0 landed
-
Fix 004_subscription.pl to allow its usage in --link mode.
- f17529b71097 17.0 landed
-
Allow upgrades to preserve the full subscription's state.
- 9a17be1e244a 17.0 landed
-
Prevent startup of logical replication launcher during pg_upgrade
- 7021d3b17664 17.0 landed