Re: Initial COPY of Logical Replication is too slow - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Initial COPY of Logical Replication is too slow
Date
Msg-id CAD21AoCc3bnpownF=VO=r=xMTZT-6aigSvZB4b0Ts1azbWq6xw@mail.gmail.com
Whole thread
In response to Re: Initial COPY of Logical Replication is too slow  (Marcos Pegoraro <marcos@f10.com.br>)
List pgsql-hackers
On Fri, Mar 27, 2026 at 6:07 AM Marcos Pegoraro <marcos@f10.com.br> wrote:
>
> Em sex., 27 de mar. de 2026 às 03:20, Masahiko Sawada <sawada.mshk@gmail.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
dueto the overload. 
> That was because max_sync_workers_per_subscription was set to 10, which caused 10 simultaneous connections to call
thisfunction immediately after the refresh publication command. 
> Wouldn't it be good to document on this GUC that if your publisher server is running version <= 18 then is it
advisableto 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
thistrouble. 
> 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,

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LLVM 22
Next
From: "Peter 'PMc' Much"
Date:
Subject: Re: Need help debugging SIGBUS crashes