Re: VACUUM/ANALYZE double-count the backend's own pending table stats

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: Sebastian Webber <sebastian(at)swebber(dot)me>, Staroverov Ilja <i(dot)staroverov(at)ftdata(dot)ru>
Subject: Re: VACUUM/ANALYZE double-count the backend's own pending table stats
Date: 2026-10-14 22:53:18
Message-ID: 179201839892.428296.16825605295501302418@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Sebastian,

> if a flush slips in between statements on a slow animal, it also
> passes without the fix, so it may not catch a regression there.

Good point. Pinning the flush in the test so it cannot pass without
the fix is easy to add; I will leave that for Ilya's v2 unless he
would rather I post it.

Thanks also for the independent confirmation and the autovacuum
numbers, and for digging up 81e82a2bd48 as a precedent. That settles
the "just an approximation" question.

Regards,
Manu

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-10-15 00:12:45 Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows
Previous Message Sebastian Webber 2026-10-14 20:28:17 Re: VACUUM/ANALYZE double-count the backend's own pending table stats