MIME-Version: 1.0
References: 
 <CAB-JLwbBFNuASyEnZWP0Tck9uNkthBZqi6WoXNevUT6+mV8XmA@mail.gmail.com>
 <CAD21AoA6i2ui8FMZeuU_KxX4t-fM8G==zTW2Dp6-goujttrpew@mail.gmail.com>
 <CAB-JLwZpp=7c9_r0beWWJxRh2BS_2Vvth8UDv7H57DBeaqggVg@mail.gmail.com>
 <CAD21AoDT3sL2COprsRumM9zEpL1Bk5VWboK4V2mRnjGua8xfeA@mail.gmail.com>
 <CAD21AoDQM62GOtaTzD_CVMSsFhv6o9c0Au1dSM1QuxeKFkWAKw@mail.gmail.com>
 <CAD21AoCz7HjEr3oeb=haK31YHxHZLcvD_wx_a-+xLPKywq++3A@mail.gmail.com>
 <TY4PR01MB16907733B75A99117F013AFCA947FA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAD21AoA9YgiY1rVKMPZwB00WU_G4UfzoawY=7hyd7hpvBPcK6w@mail.gmail.com>
 <CAA4eK1KoSi60dtakJzn0MxNnHF1Yf4indSAffTjJxQG_31jsgQ@mail.gmail.com>
 <CAD21AoB4B3MOxJ7-v9YLjV5fTOtaLRUhX3jN3kqhEi7D7-uY4A@mail.gmail.com>
 <0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info>
 <CAD21AoCmHpKrNg9D3mcOA973CZ5N_dBLxb8pERpSxEeRLSQxpA@mail.gmail.com>
 <CAD21AoAEVyxwn_bMWHvcU-Gcz3aUVjAtMbdgfoJ8MZNiLLEh0g@mail.gmail.com>
 <CAA4eK1Jkouj=w+PHzMB6v890ES3QOLf=cUTvZmGFr-WMQW2OnA@mail.gmail.com>
 <CAD21AoB4_n7+s=uM9apX1JVtvGvgM8ismAx_uMxvDmUXfQULsw@mail.gmail.com>
 <CAD21AoBJcxRcaWQot302diaxoDcsnezRhnZa7p8UrPh5AGNeHQ@mail.gmail.com>
 <CAA4eK1+ATysKLptbK+x8ygB7OAa=LHw3XTqMxKjVMsTRfdbRzQ@mail.gmail.com>
 <CAD21AoCLodVegaB=HDfxFMe8s9TMUxj+okznt6yjizN+5TVOfA@mail.gmail.com>
 <OS9PR01MB1214992889432F8A936AAAA32F557A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <CAA4eK1LR4GaoqD_pt-KZrroCTaQZ3HCT3BiU1qGTRQLWpNRHmg@mail.gmail.com>
 <CAD21AoCzACbf=FwZ11v6uLHAPDC_+zSDwmj7cpabOkDbTAKa8w@mail.gmail.com>
 <CAB-JLwYWdp87HCsJn1p0gedck-1ECH+rsj0WFG3WQPWqrvjgVA@mail.gmail.com>
In-Reply-To: 
 <CAB-JLwYWdp87HCsJn1p0gedck-1ECH+rsj0WFG3WQPWqrvjgVA@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Tue, 31 Mar 2026 17:03:23 -0700
Message-ID: 
 <CAD21AoCc3bnpownF=VO=r=xMTZT-6aigSvZB4b0Ts1azbWq6xw@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: Marcos Pegoraro <marcos@f10.com.br>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 Jan Wieck <jan@wi3ck.info>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAD21AoCc3bnpownF%3DVO%3Dr%3DxMTZT-6aigSvZB4b0Ts1azbWq6xw%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 27, 2026 at 6:07=E2=80=AFAM Marcos Pegoraro <marcos@f10.com.br>=
 wrote:
>
> Em sex., 27 de mar. de 2026 =C3=A0s 03:20, Masahiko Sawada <sawada.mshk@g=
mail.com> escreveu:
>>
>> I've attached the updated patch. I believe I've addressed all comments
>> I got so far. In addition to that, I've refactored
>> is_table_publishable_in_publication() and added more regression tests.
>
>
> Today I had to create a few more schemas and see that problem again, how =
the publisher is affected, almost crashing due to the overload.
> That was because max_sync_workers_per_subscription was set to 10, which c=
aused 10 simultaneous connections to call this function immediately after t=
he refresh publication command.
> Wouldn't it be good to document on this GUC that if your publisher server=
 is running version <=3D 18 then is it advisable to set this GUC to a reall=
y low value ?
> Because ok, version 19 is fine, will be covered, but all publisher server=
s that are not updated will continue to have this trouble.
> The publisher will be severely penalized when the subscription refreshes =
its publication.
>
> What do you think, change something on DOCs too ?

I agree that the publisher overload is a serious issue that users
should be aware of. But I'm not sure it's a good idea to broadly
suggest lowing the GUC value as it ultimatly depends on multiple
factors. A value of 10 or more is perfectly fine depending on the
hardware and the number of tables etc. A definition of a large number
of tables also varies on systems. I guess the release note would be a
better place to mention this.

Regards,

--=20
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com