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
signature.asc
Description: PGP signature
