Re: Initial COPY of Logical Replication is too slow

On Fri, Mar 27, 2026 at 6:07 AM Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:
>
> Em sex., 27 de mar. de 2026 às 03:20, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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 <= 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 ?

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