public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Smith <[email protected]>
To: Amit Kapila <[email protected]>
Cc: shveta malik <[email protected]>
Cc: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: Nisha Moond <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Subject: Re: Synchronizing slots from primary to standby
Date: Wed, 31 Jan 2024 16:10:16 +1100
Message-ID: <CAHut+PtsjpdJaXrKLaLM1Ujqh7CtUc6Vijvy972uYALitfAxaQ@mail.gmail.com> (raw)
In-Reply-To: <CAA4eK1K_5v+c8wyWDAdneTX3rEwVuzPX3bKhU_RtROitEcTgRg@mail.gmail.com>
References: <[email protected]>
<CAJpy0uBc6H22RbNVU213AZ_BPw+uDptcTVHakKegpTCv74yN=w@mail.gmail.com>
<CAA4eK1JZDtRFPJaeaLvj74760pcvaEAVxNPN0+oW5A4jL1WCBg@mail.gmail.com>
<[email protected]>
<CAA4eK1JPB-zpGYTbVOP5Qp26tNQPMjDuYzNZ+a9RFiN5nE1tEA@mail.gmail.com>
<CAJpy0uAmbh_1pH-eG5bTbHXXq9w-uNV45DT-12TTh9kGj2HeCw@mail.gmail.com>
<CAFPTHDbsZ+pxAubb9d9BwVNt5OB3_2s77bG6nHcAgUPPhEVmMQ@mail.gmail.com>
<CAJpy0uBqS_HD30mBR0yD1SVCvUZDrw1=dwn1xH8ANEQw7gnPdw@mail.gmail.com>
<CAA4eK1Lxvfq9RwOEsguiMCrKPUc1He9UGz1_wi0N0cJaXFa4Eg@mail.gmail.com>
<OS0PR01MB5716E304C26E6ACE0BE84925947A2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<[email protected]>
<CAA4eK1K0jRXa2AhKXRVDY+Y42MG4RTbfAEcTBEGN2ov=Yjco+A@mail.gmail.com>
<OS0PR01MB571623B1D01003F99A7BB983947A2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAA4eK1+3jV839U3+DGgHrgrhtDguaVwAyb0Hucz9UbpjjVL=Sg@mail.gmail.com>
<OS0PR01MB5716DE2A364CB23F9144AED194782@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAHut+PsaPJzbTAFjXkRE0uJYk+xNAdOHEnoBFTvazsRZfYSU3Q@mail.gmail.com>
<CAA4eK1+LnPajBsCXwCKbmOtDSJ=WWnXR+sHnTWav5OL3rebyyw@mail.gmail.com>
<CAJpy0uAv2dS+NTw1X1uZep11WM24Wog2kN1oqJu4Zx4xjpgwig@mail.gmail.com>
<CAA4eK1L6yoEs0OveL9xB+jopyp=Eps4ViU3JXhfpz0-2H3XCrg@mail.gmail.com>
<OS0PR01MB5716303C750A3D2FB71B77CD947E2@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAA4eK1KkfVi-LCwHYd9B2xq-Q_2i0K-xwx1vnRoxFvG1n5SbNw@mail.gmail.com>
<CAJpy0uBwhbq=c+qYfnOifu0vTo1DvOxDnJCd1ragZxe2K8=nDw@mail.gmail.com>
<CAHut+PtOF31g0=mVkU=xO7cWVc3g21BeyS1m5yRxgFMuD3znXg@mail.gmail.com>
<CAA4eK1K_5v+c8wyWDAdneTX3rEwVuzPX3bKhU_RtROitEcTgRg@mail.gmail.com>
On Wed, Jan 31, 2024 at 2:18 PM Amit Kapila <[email protected]> wrote:
>
> On Wed, Jan 31, 2024 at 7:27 AM Peter Smith <[email protected]> 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/[email protected]...
Kind Regards,
Peter Smith.
Fujitsu Australia.
view thread (119+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Synchronizing slots from primary to standby
In-Reply-To: <CAHut+PtsjpdJaXrKLaLM1Ujqh7CtUc6Vijvy972uYALitfAxaQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox