On Fri, Mar 27, 2026 at 6:07 AM Marcos Pegoraro <[email protected]> wrote: > > Em sex., 27 de mar. de 2026 às 03:20, Masahiko Sawada <[email protected]> > 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
