Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id adb6vVe4-JVq8RgU@nathan
Whole thread Raw
In response to Re: Add pg_stat_autovacuum_priority  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Add pg_stat_autovacuum_priority
List 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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Centralised architecture detection
Next
From: Xuneng Zhou
Date:
Subject: Re: Use proc_exit() in WalRcvWaitForStartPosition