Re: Add pg_stat_autovacuum_priority

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, satyanarlapuram(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tndrwang(at)gmail(dot)com
Subject: Re: Add pg_stat_autovacuum_priority
Date: 2026-04-08 18:37:31
Message-ID: adaga-DMFE2KnhXO@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 08, 2026 at 01:28:06PM -0500, Sami Imseih wrote:
>> + if (AmAutoVacuumWorkerProcess())
>> + pfree(tabentry);
>> }
>
> This works too, but v1-0001 is more generalized and we don't have to
> care about who the caller is when deciding to free or not.

Well, I think if we were building this view from scratch without any
knowledge of autovacuum, we probably wouldnt bother manually freeing the
stats entries based on the value of the GUC. We'd probably just let the
commit/abort code take care of it, which AFAICT is what we do elsewhere.
Manually freeing the entries is also risky, which commit 02502c1bca touches
on:

Note: pfree'ing the PgStat_StatTabEntry structs here seems a bit
risky, because pgstat_fetch_stat_tabentry_ext does not guarantee
anything about whether its result is long-lived. It appears okay
so long as autovacuum forces PGSTAT_FETCH_CONSISTENCY_NONE, but
I think that API could use a re-think.

This seems very much to be an autovacuum-specific hack that we shouldn't be
propagating elsewhere.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-04-08 18:44:30 Re: Add pg_stat_autovacuum_priority
Previous Message Sami Imseih 2026-04-08 18:28:06 Re: Add pg_stat_autovacuum_priority