public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: [email protected]
Cc: pgsql-hackers <[email protected]>
Cc: [email protected]
Subject: Re: Add pg_stat_autovacuum_priority
Date: Wed, 8 Apr 2026 14:44:30 -0400
Message-ID: <c4ftgtosizlzwo65kurhsbjhvtvq4qilfsfdbwnwohn6fsqpg6@5t5aspbgkifc> (raw)
In-Reply-To: <adaga-DMFE2KnhXO@nathan>
References: <CAA5RZ0tYzPDeXbqz9uKacRV2xjD055qrg=s3w2PEQPK8EruuSg@mail.gmail.com>
	<adFiCgN22xJ7Z-oR@nathan>
	<CAA5RZ0vRP-W2wJD2OxEb-=VGj2sp5pMCqHQg9YJiuDVPhaY5jQ@mail.gmail.com>
	<adQsdvPPNviWMCXb@nathan>
	<[email protected]>
	<[email protected]>
	<adaWuTR7oCKodH7k@nathan>
	<adacEjlRZco26f0h@nathan>
	<CAA5RZ0tUq7SEHvAPkYpCw7Y4XOoWLPpsfxO2ZQ5AzQRcQMMAgg@mail.gmail.com>
	<adaga-DMFE2KnhXO@nathan>

Hi,

On 2026-04-08 13:37:31 -0500, Nathan Bossart wrote:
> 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.

Agreed.  There aren't that many callers of pgstat_fetch_entry (even if you
count indirect ones), I think the best path might be to add a bool *may_free
argument where necessary and just deal with the size of change that brings
with it.

Greetings,

Andres Freund

view thread (60+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Add pg_stat_autovacuum_priority
  In-Reply-To: <c4ftgtosizlzwo65kurhsbjhvtvq4qilfsfdbwnwohn6fsqpg6@5t5aspbgkifc>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox