On Wed, Jan 31, 2024 at 2:18 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jan 31, 2024 at 7:27 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > 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. > > > > So, won't when connect=false, the user has to explicitly provide such > values (create_slot, enabled, etc.) as false? If so, is using 'force' > strictly correct?
Perhaps the original docs text could be worded differently; I think the word "force" here just meant setting connection=false forces/causes/makes those other options behave "as if" they had been set to false without the user explicitly doing anything to them. The point is they are made to behave *differently* to their normal defaults. So, connect=false ==> this actually sets enabled=false (you can see this with \dRs+), which is different to the default setting of 'enabled' connect=false ==> will not create a slot (because there is no connection), which is different to the default behaviour for 'create-slot' connect=false ==> will not copy tables (because there is no connection), which is different to the default behaviour for 'copy_data;' OTOH, failover is different connect=false ==> failover is not possible (because there is no connection), but the 'failover' default is false anyway, so no change to the default behaviour for this one. > > > ~~~ > > > > 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? > > > > AFAICS, the committed docs says: "To initiate replication, you must > manually create the replication slot, enable the failover if required, > ...". I am not sure what you are referring to. > My mistake. I was misreading the patch code without applying the patch. Sorry for the noise. > > > > ====== > > 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? > > > > Again the quoted wording is not introduced by this patch. But, I see > your point and it is better if you can start a separate thread for it. > OK. I created a separate thread for this [1] ====== [1] https://www.postgresql.org/message-id/cahut+pu1uslphrysptacy1k_q-ddsrxnfhmj_2u1nfqbc1y...@mail.gmail.com Kind Regards, Peter Smith. Fujitsu Australia.