On Wed, Apr 08, 2026 at 12:56:09PM -0500, Nathan Bossart wrote:
> Hm. I can't get excited about checking pgstat_fetch_consistency (as
> proposed in that other report), but I see that commit 02502c1bca added the
> freeing behavior in question. I wonder if it makes sense to just skip
> freeing when relation_needs_vacanalyze() is called from the view, i.e., not
> an autovacuum worker. On the other hand, maybe we shouldn't be caching
> entries for a view like this that looks through all tables in the
> database...
Concretely, this is what I'm thinking:
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index bd626a16363..6d4a34257fb 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -3327,7 +3327,15 @@ relation_needs_vacanalyze(Oid relid,
anltuples, anlthresh, scores->anl,
scores->xid, scores->mxid);
- pfree(tabentry);
+ /*
+ * Avoid leaking pgstat entries until the end of autovacuum. Elsewhere,
+ * we let the commit/abort machinery take care of freeing it. While
+ * autovacuum workers set stats_fetch_consistency to "none", it might be
+ * set to a different value in other processes, so we can't safely free it
+ * here for them.
+ */
+ if (AmAutoVacuumWorkerProcess())
+ pfree(tabentry);
}
/*
--
nathan
