Re: per backend WAL statistics
От | Michael Paquier |
---|---|
Тема | Re: per backend WAL statistics |
Дата | |
Msg-id | Z89-gxOVxtEP_w9d@paquier.xyz обсуждение исходный текст |
Ответ на | Re: per backend WAL statistics (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: per backend WAL statistics
Re: per backend WAL statistics Re: per backend WAL statistics |
Список | pgsql-hackers |
On Mon, Mar 10, 2025 at 11:52:26AM +0000, Bertrand Drouvot wrote: > 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]). We still apply the memset(), and the initialization is actually the same. > 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). Yes, restricting this check to apply on the PgStat_PendingIO makes sense. > 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. Still the blocks with the comments become a bit weird if formulated this way. Kept this one the same as v17. And I guess that we're OK here, so applied. That should be the last one. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: