Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vDwam-001lEv-Ts for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Oct 2025 03:11:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vDwal-00GJSr-Qg for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Oct 2025 03:11:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vDwal-00GJSi-Cx for pgsql-hackers@lists.postgresql.org; Wed, 29 Oct 2025 03:11:18 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vDwac-004JPA-2B for pgsql-hackers@postgresql.org; Wed, 29 Oct 2025 03:11:17 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-63e0abe71a1so12615623a12.1 for ; Tue, 28 Oct 2025 20:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761707468; x=1762312268; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZC9HaNJbhUWtgtg3F3ve0Uwig0+jrnbnWqKGIzOBLuQ=; b=CtGrROaWWum9V+Lc1lfIMVMGkNEpbq0XSYdVofwXzahWYClSpJIdOdYg5qcsiAqJq8 ffYzJpbxgWhs6szPwohrWJ/0zxoS1c3h0A6jph/8ZUrDnVOBBg7WwCHMl7EEqBHBokWc Nk2tx+dzfi4KnvntZJ0352cte5Pj3QkRZFHqp8ODmrVv4wJuFl1gm+SSqJqwqGzbFR9t N5tPwrEOA0BMQ3dVmo9fjiDaq69myF48n9akb9Mr5VcoIclZsqYwlx+RLvi0TIzJlRK+ zphBCa6SfWUMGkyN97AVgU3HWQrVbNfuUn2I5KrvRn8cM18ByPW4qTalvjqztFA4qVMv GN6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761707468; x=1762312268; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZC9HaNJbhUWtgtg3F3ve0Uwig0+jrnbnWqKGIzOBLuQ=; b=MOUHtt4rg0w58s9y4LH6VBoL8aedyuf6wF/glSKdd/d0bk1FNXSg+5iN7jeJvQWLi9 DTgh3mLoZFAD0QllxrprDSrVpR5S6/NPDD8vXwErBEhR03TkZ7cA7mrx+53pXCTRiGYs JhjGyfDOciOKyvF9oY/X3p/gDt5HEslIflii5tZ7yRdJfhbi79rl+QbcLwekuTK+a2zw NTljjBwwcP4rfPlUteXy9p8VwfxhW5dTJO+mJvWSie5liNsMWLKSk+jcW5qBAVF61/DR 1Qgr+IiWcQOskVEiLwX7Q8rX+UuzV6SgydJ5aeXBjYt7LlfN3L/eCPWXt99dTBdq+mFO pXvg== X-Forwarded-Encrypted: i=1; AJvYcCX0cHxtTgnODdzjvYUDiBhGZXFSWWGzdVJErELfmlytchW9UOMdb4R3uf5HuOTUHXWmYrqmKpes2xu3YoJP@postgresql.org X-Gm-Message-State: AOJu0Ywxm5qVvI6ptGrjJsaZmRSWFufliNpcP0uFaMQ54NpFP2O4fkvy ZAfexHfVrj6Pc69EltD5Q0qERHWc6KeXN/aSMoSwB7X16LBxeHkqV7GBPre6XK1DWWsX9M41/nD PLkRynATiR2bZsp7McezN3zri/Tp9D8I= X-Gm-Gg: ASbGncsIvRvXbxr2LvLcTFxikmbSbcQSA+YlS3bUS9yki30SuWXptQId/W77H4pf/ry AigUfyRYSdt+UE2rcLqD8e3AgVWN6H3Ge5WqxM+aQsH6K0qz4vWQV8R7SoGkfQTYFaBj1uXEdjf 84sNvluq/oX3GWv4YoU4zMlxMSs1kYqbzEUl+YlmToZq1y0p4sHzqq8kKPOV50OWsufjGQzivIc +XpZUB1PJyXkj0FWk8LjsHfDuCARCBABU+3pFdG+Ph/vsYBs3xZSs4zMXE= X-Google-Smtp-Source: AGHT+IG9n8F7PSiTO3WrI0tt76jsfi+p8QyMTr8ZBz+ZUVpt1QWl2Pe7d1dJhZctqwnwFLjgQTO9pZGpIr0PP3TiB58= X-Received: by 2002:a05:6402:13d6:b0:639:7307:2403 with SMTP id 4fb4d7f45d1cf-640441b6015mr896569a12.11.1761707467790; Tue, 28 Oct 2025 20:11:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: wenhui qiu Date: Wed, 29 Oct 2025 11:10:55 +0800 X-Gm-Features: AWmQ_bnPL09_1aKhEGSM9RNFWDzrySDACPaKNV_bCX-DBhTaPSpF3HvzFyRqb98 Message-ID: Subject: Re: another autovacuum scheduling thread To: Sami Imseih Cc: Nathan Bossart , David Rowley , Robert Haas , Jeremy Schneider , pgsql-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000d0db9c0642437bbb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d0db9c0642437bbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Nathan Bossart > + if (vactuples > vacthresh) > + { > + *dovacuum =3D true; > + *score =3D Max(*score, (double) vactuples / Max(vacthresh, 1)); > + } > + > + if (vac_ins_base_thresh >=3D 0 && instuples > vacinsthresh) > + { > + *dovacuum =3D true; > + *score =3D *score =3D Max(*score, (double) instuples / Max(vacinsthresh= , 1)); > + } I think it ( *score =3D *score =3D Max(*score, (double) instuples / Max(vacinsthresh, 1));) I believe this must be a slip of the hand on your part, having copied an extra one. I also suggest add debug log for score ereport(DEBUG2, (errmsg("autovacuum candidate: %s (score=3D%.3f)", get_rel_name(table->oid), table->score))); > + effective_xid_failsafe_age =3D Max(vacuum_failsafe_age, > + autovacuum_freeze_max_age * 1.05); Typically, DBAs avoid setting autovacuum_freeze_max_age too close to vacuum_failsafe_age. Therefore, your logic most likely uses the vacuum_failsafe_age value. Would taking the average of the two be a better approach? # root@localhost:/data/pgsql/pg18data# grep vacuum_failsafe_age postgresql.conf #vacuum_failsafe_age =3D 1600000000 root@localhost:/data/pgsql/pg18data# grep autovacuum_freeze_max_age postgresql.conf #autovacuum_freeze_max_age =3D 200000000 # maximum XID age before forced vacuum Thanks On Wed, Oct 29, 2025 at 6:45=E2=80=AFAM Sami Imseih w= rote: > > Done. > > My compiler is complaining about v6 > > "../src/backend/postmaster/autovacuum.c:3293:32: warning: operation on > =E2=80=98*score=E2=80=99 may be undefined [-Wsequence-point] > 3293 | *score =3D *score =3D Max(*score, (double= ) > instuples / Max(vacinsthresh, 1)); > [2/2] Linking target src/backend/postgres" > > shouldn't just be like below? > > *score =3DMax(*score, (double) instuples / Max(vacinsthresh, 1)); > > > -- > Sami > > > --000000000000d0db9c0642437bbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Nathan Bossart=C2=A0

> + if (vac= tuples > vacthresh)
> + {
> + *dovacuum =3D true;
>= + *score =3D Max(*score, (double) vactuples / Max(vacthresh, 1));
>= ; + }
> +
> + if (vac_ins_base_thresh >=3D 0 && in= stuples > vacinsthresh)
> + {
> + *dovacuum =3D true;
= > + *score =3D *score =3D Max(*score, (double) instuples / Max(vacinst= hresh, 1));
> + }
=C2=A0I think it (=C2=A0*score =3D *score =3D Max(*score, (double) inst= uples / Max(vacinsthresh, 1));)=C2=A0I believe this must be a slip of the h= and on your part, having copied an extra one.
I also suggest = add debug log for score=C2=A0
=C2=A0 =C2=A0 ereport(DEBUG2,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (errmsg("autovacuum candidat= e: %s (score=3D%.3f)",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 get_rel_name(table->oid), table->score)))= ;

> + effective_xid_failsafe_age =3D Max(vacuu= m_failsafe_age,
> + autovacuum_freeze_max_age * = 1.05);
Typically, DBAs avoid setting autovacuum_freeze_max_ag= e too close to vacuum_failsafe_age. Therefore, your logic most likely uses = the vacuum_failsafe_age value.
Would taking the average of th= e two be a better approach?
#
root@localhost:/data/= pgsql/pg18data# grep vacuum_failsafe_age postgresql.conf
#vacuum_failsaf= e_age =3D 1600000000
root@localhost:/data/pgsql/pg18data# grep autovacuu= m_freeze_max_age postgresql.conf
#autovacuum_freeze_max_age =3D 20000000= 0 # maximum XID age before forced vacuum


<= br>
Thanks=C2=A0

On Wed, Oct 29, 2025 = at 6:45=E2=80=AFAM Sami Imseih <s= amimseih@gmail.com> wrote:
> Done.

My compiler is complaining about v6

"../src/backend/postmaster/autovacuum.c:3293:32: warning: operation on=
=E2=80=98*score=E2=80=99 may be undefined [-Wsequence-point]
=C2=A03293 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0*score =3D *score =3D Max(*score, (double)
instuples / Max(vacinsthresh, 1));
[2/2] Linking target src/backend/postgres"

shouldn't just be like below?

*score =3DMax(*score, (double) instuples / Max(vacinsthresh, 1));


--
Sami


--000000000000d0db9c0642437bbb--