Re: Add pg_stat_autovacuum_priority

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-09 01:02:53
Message-ID: adb6vVe4-JVq8RgU@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 08, 2026 at 06:51:59PM -0500, Sami Imseih wrote:
> I went ahead and implemented Andres's idea of will_free. Callers of
> pgstat_fetch_entry can either pass a NULL to a will_free parameter,
> or a bool. Callers that pass the bool can check if will_free is true and
> can choose to free the entry.

Yeah, I think this is the right thing to do. IMHO "may_free" is slightly
more accurate here, since we're telling the caller that they can explicitly
pfree() the result instead of letting the pgstat machinery or their own
memory context take care of it.

+ /*
+ * When pgstat_fetch_consistency is PGSTAT_FETCH_CONSISTENCY_NONE, callers
+ * will be responsible for freeing the entry.
+ */
+ if (will_free)
+ *will_free = (pgstat_fetch_consistency == PGSTAT_FETCH_CONSISTENCY_NONE);

I don't know if this is a strict project guideline, but when I add these
sorts of function parameters I usually just require the caller to provide a
non-NULL pointer. But... what you have here seems fine, too.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-04-09 01:09:08 Re: Use proc_exit() in WalRcvWaitForStartPosition
Previous Message Thomas Munro 2026-04-09 01:01:41 Centralised architecture detection