Re: per backend WAL statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: per backend WAL statistics
Date
Msg-id Z89-gxOVxtEP_w9d@paquier.xyz
Whole thread Raw
In response to Re: per backend WAL statistics  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: per backend WAL statistics
Re: per backend WAL statistics
Re: per backend WAL statistics
List 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

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Parallel heap vacuum
Next
From: Michael Paquier
Date:
Subject: Re: Memory context can be its own parent and child in replication command