Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Vaibhav Jain <jainva(at)google(dot)com>, pg(at)bowt(dot)ie, andres(at)anarazel(dot)de
Subject: Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting
Date: 2026-11-13 07:08:06
Message-ID: CAN4CZFN5OkVm6hpEFJx0pfFh0kgVkBwpmpG70GbNmwOMOS=aBw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 13 Nov 2026, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> So I did mean for a sentinel/unknown value to be returned here.
> However, it looks like the value should be 0 and not -1.

Sorry if that wasn't clear from my email, I didn't question the value
changing, only the part where the -1 is visible to users, as that
seems like a preexisting bug that now got one more case.

> So, to clamp it, we should save the return value of
> vac_estimate_reltuples() in a double and clamp it to 0 before
> assigning to stat->tuple_count.

Yes, either that or tuple_count should be signed, but the current way
doesn't seem to be good.

One more nit for the original v2-0001:

+ * value when at most one page was scanned. When the relation size has
+ * changed, use the old density to account for the added or removed pages
+ * instead of preserving a stale tuple count.
*
* (Note: we might be returning -1 here.)
*/

That note is now stale, with the condition moved before it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-11-13 07:10:39 Re: Add wait events for server logging destination writes
Previous Message Heikki Linnakangas 2026-11-13 06:46:59 Re: SIGFPE handling