On Wed, Apr 12, 2023 at 12:05 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Fri, Apr 7, 2023 at 10:23 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > > > > On 7 Apr 2023, at 15:07, Melanie Plageman <melanieplage...@gmail.com> > > > wrote: > > > On Fri, Apr 7, 2023 at 2:53 AM Masahiko Sawada <sawada.m...@gmail.com> > > > wrote: > > > > > > Definitely seems worth fixing as it kind of defeats the purpose of the > > > original commit. I wish I had noticed before! > > > > > > Your fix has: > > > !(avopts && (avopts->vacuum_cost_limit >= 0 || > > > avopts->vacuum_cost_delay >= 0)); > > > > > > And though delay is required to be >= 0 > > > avopts->vacuum_cost_delay >= 0 > > > > > > Limit does not. It can just be > 0. > > > > > > postgres=# create table foo (a int) with (autovacuum_vacuum_cost_limit = > > > 0); > > > ERROR: value 0 out of bounds for option "autovacuum_vacuum_cost_limit" > > > DETAIL: Valid values are between "1" and "10000". > > > > > > Though >= is also fine, the rest of the code in all versions always > > > checks if limit > 0 and delay >= 0 since 0 is a valid value for delay > > > and not for limit. Probably best we keep it consistent (though the whole > > > thing is quite confusing). > > > > +1 > > +1. I misunderstood the initial value of autovacuum_vacuum_cost_limit > reloption.
I've attached an updated patch for fixing at_dobalance condition. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
0001-Fix-the-condition-of-joining-autovacuum-workers-to-b.patch
Description: Binary data
