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

From Andres Freund
Subject Re: shared-memory based stats collector - v69
Date
Msg-id 20220405030506.lfdhbu5zf4tzdpux@alap3.anarazel.de
Whole thread Raw
In response to Re: shared-memory based stats collector - v68  (Andres Freund <andres@anarazel.de>)
Responses Re: shared-memory based stats collector - v70  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

Thanks for the reviews Justin, Thomas, David. I tried to incorporate the
feedback, with the exception of the ongoing discussion around
accessed_across_databases. I've also not renamed pg_stat_exists_stat() yet,
not clear who likes what :)

Changes in v69:

- merged feedback
- committed the first few commits, mostly pretty boring stuff
- added an architecture overview comment to the top of pgstat.c - not sure if
  it makes sense to anybody but me (and perhaps Horiguchi-san)?
- merged "only reset pgstat data after crash recovery." into the main commit,
  added tests verifying the behaviour of not resetting stats on a standby when
  in SHUTDOWNED_IN_RECOVERY.
- drop variable-amount stats when loading on-disk file fails partway through,
  I'd raised this earlier in [1]
- made most pgstat_report_stat() calls pass force = true. In worker.c, the
  only possibly frequent caller, I instead added a pgstat_report_stat(true) to
  the idle path.
- added a handful more tests, but mostly out of "test coverage vanity" ;)
- made the test output of 030_stats_cleanup_replica a bit more informative,
  plus other minor cleanups


The one definite TODO I know of is
> - fix the bug around pgstat_report_stat() I wrote about at [3]
> [3] https://www.postgresql.org/message-id/20220402081648.kbapqdxi2rr3ha3w@alap3.anarazel.de

I'd hoped Horiguchi-san would chime in on that discussion...

Regards,

Andres


[1] https://www.postgresql.org/message-id/20220329191727.mzzwbl7udhpq7pmf%40alap3.anarazel.de

Attachment

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Temporary tables versus wraparound... again
Next
From: Peter Smith
Date:
Subject: Re: Handle infinite recursion in logical replication setup