Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers
From | Peter Smith |
---|---|
Subject | Re: Synchronizing slots from primary to standby |
Date | |
Msg-id | CAHut+PtOF31g0=mVkU=xO7cWVc3g21BeyS1m5yRxgFMuD3znXg@mail.gmail.com Whole thread Raw |
In response to | Re: Synchronizing slots from primary to standby (shveta malik <shveta.malik@gmail.com>) |
Responses |
Re: Synchronizing slots from primary to standby
RE: Synchronizing slots from primary to standby |
List | pgsql-hackers |
Hi, I saw that v73-0001 was pushed, but it included some last-minute changes that I did not get a chance to check yesterday. Here are some review comments for the new parts of that patch. ====== doc/src/sgml/ref/create_subscription.sgml 1. connect (boolean) Specifies whether the CREATE SUBSCRIPTION command should connect to the publisher at all. The default is true. Setting this to false will force the values of create_slot, enabled, copy_data, and failover to false. (You cannot combine setting connect to false with setting create_slot, enabled, copy_data, or failover to true.) ~ I don't think the first part "Setting this to false will force the values ... failover to false." is strictly correct. I think is correct to say all those *other* properties (create_slot, enabled, copy_data) are forced to false because those otherwise have default true values. But the 'failover' has default false, so it cannot get force-changed at all because you can't set connect to false when failover is true as the second part ("You cannot combine...") explains. IMO remove 'failover' from that first sentence. ~~~ 2. <para> Since no connection is made when this option is <literal>false</literal>, no tables are subscribed. To initiate replication, you must manually create the replication slot, enable - the subscription, and refresh the subscription. See + the failover if required, enable the subscription, and refresh the + subscription. See <xref linkend="logical-replication-subscription-examples-deferred-slot"/> for examples. </para> IMO "see the failover if required" is very vague. See what failover? The slot property failover, or the subscription option failover? And "see" it for what purpose? I think the intention was probably to say something like "ensure the manually created slot has the same matching failover property value as the subscriber failover option", but that is not clear from the current text. ====== doc/src/sgml/ref/pg_dump.sgml 3. dump can be restored without requiring network access to the remote servers. It is then up to the user to reactivate the subscriptions in a suitable way. If the involved hosts have changed, the connection - information might have to be changed. It might also be appropriate to + information might have to be changed. If the subscription needs to + be enabled for + <link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>, + then same needs to be done by executing + <link linkend="sql-altersubscription-params-set"> + <literal>ALTER SUBSCRIPTION ... SET(failover = true)</literal></link> + after the slot has been created. It might also be appropriate to "then same needs to be done" (English?) BEFORE If the subscription needs to be enabled for failover, then same needs to be done by executing ALTER SUBSCRIPTION ... SET(failover = true) after the slot has been created. SUGGESTION If the subscription needs to be enabled for failover, execute ALTER SUBSCRIPTION ... SET(failover = true) after the slot has been created. ====== src/backend/commands/subscriptioncmds.c 4. #define SUBOPT_RUN_AS_OWNER 0x00001000 -#define SUBOPT_LSN 0x00002000 -#define SUBOPT_ORIGIN 0x00004000 +#define SUBOPT_FAILOVER 0x00002000 +#define SUBOPT_LSN 0x00004000 +#define SUBOPT_ORIGIN 0x00008000 + A spurious blank line was added. ====== src/bin/pg_upgrade/t/004_subscription.pl 5. -# The subscription's running status should be preserved. Old subscription -# regress_sub1 should be enabled and old subscription regress_sub2 should be -# disabled. +# The subscription's running status and failover option should be preserved. +# Old subscription regress_sub1 should have enabled and failover as true while +# old subscription regress_sub2 should have enabled and failover as false. $result = $new_sub->safe_psql('postgres', - "SELECT subname, subenabled FROM pg_subscription ORDER BY subname"); -is( $result, qq(regress_sub1|t -regress_sub2|f), + "SELECT subname, subenabled, subfailover FROM pg_subscription ORDER BY subname"); +is( $result, qq(regress_sub1|t|t +regress_sub2|f|f), "check that the subscription's running status are preserved"); ~ Calling those "old subscriptions" seems misleading. Aren't these the new/upgraded subscriptions being checked here? Should the comment be more like: # The subscription's running status and failover option should be preserved. # Upgraded regress_sub1 should still have enabled and failover as true. # Upgraded regress_sub2 should still have enabled and failover as false. ====== Kind Regards, Peter Smith. Fujitsu Australia.
pgsql-hackers by date: