| 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
| 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 |