Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1wAY1s-0004wH-0j
	for pgsql-hackers@arkaria.postgresql.org;
	Wed, 08 Apr 2026 18:53:32 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.96)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1wAY1q-001QZ3-0h
	for pgsql-hackers@arkaria.postgresql.org;
	Wed, 08 Apr 2026 18:53:31 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1wAY1p-001QYu-2y
	for pgsql-hackers@lists.postgresql.org;
	Wed, 08 Apr 2026 18:53:30 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.98.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1wAY1l-000000003CQ-16bM
	for pgsql-hackers@postgresql.org;
	Wed, 08 Apr 2026 18:53:30 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 638IrKD83097985;
	Wed, 8 Apr 2026 14:53:20 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>, Sami Imseih <samimseih@gmail.com>,
        Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
        Robert Treat <rob@xzilla.net>, satyanarlapuram@gmail.com,
        pgsql-hackers <pgsql-hackers@postgresql.org>, tndrwang@gmail.com
Subject: Re: Add pg_stat_autovacuum_priority
In-reply-to: <adaWuTR7oCKodH7k@nathan>
References: 
 <CAA5RZ0t6bCR6Pasd_eWqXvyUmrNDWmHUy1yN_Po-c4+b9BtBqQ@mail.gmail.com>
 <adEhRzu4YM7ztLXr@nathan>
 <CAA5RZ0vxby2osMMaCuZ=680tmt583cF9n4rOzTGdsiS-1PJknA@mail.gmail.com>
 <adE9RbcA7lhH_w2d@nathan>
 <CAA5RZ0tYzPDeXbqz9uKacRV2xjD055qrg=s3w2PEQPK8EruuSg@mail.gmail.com>
 <adFiCgN22xJ7Z-oR@nathan>
 <CAA5RZ0vRP-W2wJD2OxEb-=VGj2sp5pMCqHQg9YJiuDVPhaY5jQ@mail.gmail.com>
 <adQsdvPPNviWMCXb@nathan> <5684f479-858e-4c5d-b8f5-bcf05de1f909@gmail.com>
 <3077290.1775668665@sss.pgh.pa.us> <adaWuTR7oCKodH7k@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Wed, 08 Apr 2026 12:56:09 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3097983.1775674400.1@sss.pgh.pa.us>
Date: Wed, 08 Apr 2026 14:53:20 -0400
Message-ID: <3097984.1775674400@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/3097984.1775674400%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> 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...

<carp>
Oh.  I'm not happy that any part of autovacuum.c is now reachable from
SQL: that's the sort of modularity violation that will bite us on the
ass (indeed just did).  Aside from this problem, the elog's that
relation_needs_vacanalyze emits seem 100% inappropriate and misleading
when it's being called from the view.
</carp>

I think perhaps the right way forward is to rethink the API
guarantees for pgstat_fetch_stat_tabentry_ext, as I speculated
about in 02502c1bc:

    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.

I didn't want to do any such thing in a bug fix that needed to be
back-patched, but I see no reason we couldn't redefine that API
for v19.  Plausible alternatives:

1. Always return a freshly palloc'd struct.  Potentially adds
cycles, adds risk of a leak if caller forgets to pfree.

2. Add a "bool *should_free" parameter, like we have in tuplestores
and some other places.  It's on the caller to pfree if should_free
gets set, but since we'd have to touch every caller, we'd not miss
any.

3. Add a "bool please_palloc" parameter, signaling the caller's
intent to pfree.  Probably has no advantage over #2 though.

			regards, tom lane