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>
In-Reply-To: 
 <CAD21AoCzACbf=FwZ11v6uLHAPDC_+zSDwmj7cpabOkDbTAKa8w@mail.gmail.com>
From: Marcos Pegoraro <marcos@f10.com.br>
Date: Fri, 27 Mar 2026 10:07:11 -0300
Message-ID: 
 <CAB-JLwYWdp87HCsJn1p0gedck-1ECH+rsj0WFG3WQPWqrvjgVA@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: Masahiko Sawada <sawada.mshk@gmail.com>
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: multipart/alternative; boundary="0000000000000f9f44064e0130b1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB-JLwYWdp87HCsJn1p0gedck-1ECH%2Brsj0WFG3WQPWqrvjgVA%40mail.gmail.com>
Precedence: bulk

--0000000000000f9f44064e0130b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Em sex., 27 de mar. de 2026 =C3=A0s 03:20, Masahiko Sawada <sawada.mshk@gma=
il.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
caused 10 simultaneous connections to call this function immediately after
the 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 really
low value ?
Because ok, version 19 is fine, will be covered, but all publisher servers
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 ?

regards
Marcos

--0000000000000f9f44064e0130b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Em sex., 27 de mar.=
 de 2026 =C3=A0s 03:20, Masahiko Sawada &lt;<a href=3D"mailto:sawada.mshk@g=
mail.com" target=3D"_blank">sawada.mshk@gmail.com</a>&gt; escreveu:</div></=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">I&#39;ve attached the updated patch. I believe I&#39;ve addressed all=
 comments<br>
I got so far. In addition to that, I&#39;ve refactored<br>
is_table_publishable_in_publication() and added more regression tests.<br><=
/blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-=
family:verdana,sans-serif;color:rgb(102,102,102)">Today I had to create a f=
ew more schemas and see that problem again, how the publisher is affected, =
almost crashing due to the overload.=C2=A0</div><div class=3D"gmail_default=
" style=3D"font-family:verdana,sans-serif;color:rgb(102,102,102)">That was =
because max_sync_workers_per_subscription was set to 10, which caused 10 si=
multaneous connections to call this function immediately after the refresh =
publication command.=C2=A0</div></div><div class=3D"gmail_default" style=3D=
"font-family:verdana,sans-serif;color:rgb(102,102,102)">Wouldn&#39;t it be =
good to document on this GUC that if your publisher server is running versi=
on &lt;=3D 18 then is it advisable to set this GUC to a really low value ?<=
/div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;c=
olor:rgb(102,102,102)">Because ok, version 19 is fine, will be covered, but=
 all publisher=C2=A0servers that=C2=A0are not updated will continue to have=
 this trouble.</div><div class=3D"gmail_default" style=3D"font-family:verda=
na,sans-serif;color:rgb(102,102,102)">The publisher will be severely penali=
zed when the subscription refreshes its publication.</div><div class=3D"gma=
il_default" style=3D"font-family:verdana,sans-serif;color:rgb(102,102,102)"=
><br></div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-s=
erif;color:rgb(102,102,102)">What do you think, change something on DOCs to=
o ?</div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-ser=
if;color:rgb(102,102,102)"><br></div><div class=3D"gmail_default" style=3D"=
font-family:verdana,sans-serif;color:rgb(102,102,102)">regards</div><div cl=
ass=3D"gmail_default" style=3D"font-family:verdana,sans-serif;color:rgb(102=
,102,102)">Marcos</div></div></div>
</div>

--0000000000000f9f44064e0130b1--