Re: shared-memory based stats collector - v68 - Mailing list pgsql-hackers

Hi,

New version of the shared memory stats patchset. Most important changes:

- It's now "cumulative statistics system", as discussed at [1]. This basically
  is now the term that all the references to the "stats collector" are
  replaced with. Looks much better than "activity statistics" imo. The
  STATS_COLLECTOR is now named STATS_CUMULATIVE.  I tried to find all
  references to either collector or "activity statistics", but in all
  likelihood I didn't get them all.

- updated docs (significantly edited version of the version Kyotaro posted a
  few days ago)

- significantly improved test coverage - pgstat*.c are nearly completely
  covered. While pgstatsfuncs.c coverage has increased, it is not great - but
  there's already so much more coverage, that I think it's good enough for
  now. Thanks to Melanie for help with this!

- largely cleaned up inconsisten function / type naming. Everything now /
  again is under the PgStats_ prefix, except for statistics in shared memory,
  which is prefixed with PgStatsShared_.  I think we should go further and
  add at least a PgStatsPending_ namespace, but that requires touching plenty
  code that didn't need to be touched so far, so it'll have to be task for
  another release.

- As discussed in [2] I added a patch at the start of the queue to clean up
  the inconsistent function header comments conventions.

- pgstat.c is further split. Two new files: pgstat_xact.c and pgstat_shmem.c
  (wrote an email about this a few days ago, without sending the patches)

- Split out as much as I could into separate commits.

- Cleaned up autovacuum.c changes - mostly removing more obsolted code

- code, comment polishing



Still todo:
- docs need review
- finish writing architectural comment atop pgstat.c
- fix the bug around pgstat_report_stat() I wrote about at [3]
- collect who reviewed earlier revisions
- choose what conditions for stats file reset we want
- I'm wondering if the solution for replication slot names on disk is too
  narrow, and instead we should have a more general "serialize" /
  "deserialize" callback. But we can easily do that later as well...


There's a bit more inconsistency around function naming. Right now all
callbacks are pgstat_$kind_$action_cb, but most of the rest of pgstat is
pgstat_$action_$kind.  But somehow it "feels" wrong for the callbacks -
there's also a bunch of functions already named similarly, but that's
partially my fault in commits in the past.


There are a lot of copies of "Permission checking for this function is managed
through the normal GRANT system." in the pre-existing code. Aren't they
completely bogus? None of the functions commented upon like that is actually
exposed to SQL!


Please take a look!


Greetings,

Andres Freund

[1] https://www.postgresql.org/message-id/20220308205351.2xcn6k4x5yivcxyd%40alap3.anarazel.de
[2] https://www.postgresql.org/message-id/20220329191727.mzzwbl7udhpq7pmf%40alap3.anarazel.de
[3] https://www.postgresql.org/message-id/20220402081648.kbapqdxi2rr3ha3w@alap3.anarazel.de