Re: per backend WAL statistics
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Attachments
- v18-0001-per-backend-WAL-statistics.patch (text/x-diff)
Hi, On Mon, Mar 10, 2025 at 04:46:53PM +0900, Michael Paquier wrote: > On Sat, Mar 08, 2025 at 07:53:04AM +0000, Bertrand Drouvot wrote: > > That would not be an issue should we only access the struct > > fields in the code, but that's not the case as we're making use of > > pg_memory_is_all_zeros() on it. > > It does not hurt to keep it as it is, honestly. I believe that's worse than before actually. Before padding bytes would "probably" be set to zeros while now it's certainly not always the case. I think that we already removed this (see comments === 4 in [1]). > I've reviewed the last patch of the series Thanks! > and noticed a couple of > inconsistent comments across it, and some indentation issue. I think I ran pgindent though. Anyway, thanks for fixing those! > @@ -199,7 +258,8 @@ pgstat_flush_backend(bool nowait, bits32 flags) > return false; > > if (pg_memory_is_all_zeros(&PendingBackendStats, > - sizeof(struct PgStat_BackendPending))) > + sizeof(struct PgStat_BackendPending)) > + && !pgstat_backend_wal_have_pending()) > return false; > > I have one issue with pgstat_flush_backend() and the early exit check > done here. If for example we use FLUSH_WAL but there is some IO data > pending, we would lock the stats entry for nothing. We could also > return true even if there is no pending WAL data if the lock could not > be taken, which would be incorrect because there was no data to flush > to begin with. I think that this should be adjusted so as we limit > the entry lock depending on the flags given in input, like in the > attached. Yeah I agree this needs to be improved, thanks! + /* Some IO data pending? */ + if ((flags & PGSTAT_BACKEND_FLUSH_IO) && + !pg_memory_is_all_zeros(&PendingBackendStats, + sizeof(struct PgStat_BackendPending))) + has_pending_data = true; if PgStat_BackendPending contains more than pending_io in the future, then that would check for zeros in a too large memory region. I think it's better to check for: if (pg_memory_is_all_zeros(&PendingBackendStats.pending_io, sizeof(struct PgStat_PendingIO))) like in the attached. Or check on "backend_has_iostats" (if 0002 in [2] goes in). + /* Some WAL data pending? */ + if ((flags & PGSTAT_BACKEND_FLUSH_WAL) && + pgstat_backend_wal_have_pending()) + has_pending_data = true; I think we can use "else if" here (done in the attached) as it's not needed if has_pending_data is already set to true. That's the only 2 changes done in the attached as compared to the previous version. Regards, [1]: https://www.postgresql.org/message-id/Z44vMD/rALy8pfVE%40ip-10-97-1-34.eu-west-3.compute.internal [2]: https://www.postgresql.org/message-id/Z8WYf1jyy4MwOveQ%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Fix use-after-free in pgstat_fetch_stat_backend_by_pid()
- 3191a593d6de 18.0 landed
-
Remove initialization from PendingBackendStats
- f554a95379a9 18.0 landed
-
Add WAL data to backend statistics
- 76def4cdd7c2 18.0 landed
-
Improve check for detection of pending data in backend statistics
- 9a8dd2c5a6d9 18.0 landed
-
Fix some gaps in pg_stat_io with WAL receiver and WAL summarizer
- f4694e0f35b2 18.0 landed
-
Handle auxiliary processes in SQL functions of backend statistics
- 3f1db99bfabb 18.0 landed
-
Invent pgstat_fetch_stat_backend_by_pid()
- c2a50ac678eb 18.0 landed
-
Refactor code of pg_stat_get_wal() building result tuple
- 495864a4cf16 18.0 landed
-
Adding new PgStat_WalCounters structure in pgstat.h
- 0e42d31b0b22 18.0 landed
-
Remove pgstat_flush_wal()
- d7cbeaf261da 18.0 landed
-
Refactor some code related to backend statistics
- 2c14037bb57c 18.0 landed
-
Add backend-level statistics to pgstats
- 9aea73fc61d4 18.0 cited