Re: per backend I/O statistics

On Fri, Nov 22, 2024 at 07:49:58AM +0000, Bertrand Drouvot wrote:
> On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote:
>> Hmm. created_entry only matters for pgstat_init_function_usage().
>> All the other callers of pgstat_prep_pending_entry() pass a NULL
>> value.
>
> I meant to say all the calls that passe "create" as true in pgstat_get_entry_ref().

Ah, OK, I think that I see your point here.

I am wondering how much this would matter as well for custom stats,
but we're not there yet without at least one release out and folks try
new things with these APIs and variable-numbered kinds. Allowing
pgstat_prep_pending_entry() to return NULL even if "create" is true
may be a good thing, at the end, because that's the only way I can see
based on the current APIs where we could say "Sorry, but the stats
have not been loaded yet, so you cannot try to do anything related to
the dshash".

From my view having a kind of barrier would be cleaner in the long
run, but it's true that it may not be mandatory, as well. pg_stat_io
is currently OK to be called because the stats are loaded for
auxiliary processes because it uses fixed-numbered stats in shmem.
And it means we already have early calls that add stats getting
overwritten once the stats are loaded from the on-disk file (Am I
getting this part right?).

Anyway, do we really require that for the sake of this thread? We
know that there's only one of each auxiliary process at a time, and
they keep a footprint in pg_stat_io already. So we could just limit
outselves to live database backends, WAL senders and autovacuum
workers, everything that's not auxiliary and spawned on request?
--
Michael