On Tue, Mar 29, 2022 at 6:09 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 3/29/22 13:47, Amit Kapila wrote: > > On Tue, Mar 29, 2022 at 4:33 PM Tomas Vondra > > <tomas.von...@enterprisedb.com> wrote: > >> > >> On 3/29/22 12:00, Amit Kapila wrote: > >>>> > >>>> Thanks, I'll take a look later. > >>>> > >>> > >>> This is still failing [1][2]. > >>> > >>> [1] - > >>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican&dt=2022-03-28%2005%3A16%3A53 > >>> [2] - > >>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2022-03-24%2013%3A13%3A08 > >>> > >> > >> AFAICS we've concluded this is a pre-existing issue, not something > >> introduced by a recently committed patch, and I don't think there's any > >> proposal how to fix that. > >> > > > > I have suggested in email [1] that increasing values > > max_sync_workers_per_subscription/max_logical_replication_workers > > should solve this issue. Now, whether this is a previous issue or > > behavior can be debatable but I think it happens for the new test case > > added by commit c91f71b9dc. > > > > IMHO that'd be just hiding the actual issue, which is the failure to > sync the subscription in some circumstances. We should fix that, not > just make sure the tests don't trigger it. >
I am in favor of fixing/changing some existing behavior to make it better and would be ready to help in that investigation as well but was just not sure if it is a good idea to let some of the buildfarm member(s) fail for a number of days. Anyway, I leave this judgment to you. -- With Regards, Amit Kapila.
