Re: Use pgstat_kind_infos to read fixed shared stats structs

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tristan Partin <tristan(at)neon(dot)tech>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use pgstat_kind_infos to read fixed shared stats structs
Date: 2024-07-01 05:48:19
Message-ID: ZoJDI27hLfNhwaG8@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 08, 2024 at 10:21:56AM +0900, Michael Paquier wrote:
> Yup, I've looked at that yesterday and the read order remains the same
> so I don't see a need for a version bump.

While looking at this stuff again, I got no objections for it except a
few edits to make the new code more consistent with the surroundings,
as in the loop, the use of pgstat_get_kind_info and an extra
assertion.

Still, I think that we could be more ambitious to make this area of
the code more pluggable in the future (fixed shared stats are not
covered by my proposal on the other thread about pluggable cumulative
stats, perhaps it should but I could not think about a case for them).

Anyway, the first thing is to apply the same pattern as the read part
for pgstat_write_statsfile(), based on the content in the local stats
snapshot PgStat_Snapshot.

So, how about trying to remove the dependency to the fixed shared
stats structures in PgStat_ShmemControl and PgStat_Snapshot? I'd like
to think that these should be replaced with an area allocated in
shared memory and TopMemoryContext respectively, with PgStat_Snapshot
and PgStat_ShmemControl pointing to these areas, with an allocated
size based on the information aggregated from the KindInfo Array. We
could also store the offset of the fixed areas in two extra arrays,
one for each of the two structures, indexed by KindInfo and of size
PGSTAT_NUM_KINDS.

Thoughts?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2024-07-01 05:54:56 Assertion failure with summarize_wal enabled during pg_createsubscriber
Previous Message vignesh C 2024-07-01 05:20:52 Re: long-standing data loss bug in initial sync of logical replication