Hi, On Tue, Mar 11, 2025 at 09:06:27AM +0900, Michael Paquier wrote: > 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.
Yeah currently there is no issues: there is no padding in the struct and memset() is done. That said, memset() is done only if pgstat_tracks_backend_bktype() returns true (i.e if pgstat_create_backend() is called). That means that if, in the future, the struct is modified in such a way that padding is added, then we could end up with non zeros padding bytes for the backends for which pgstat_tracks_backend_bktype() returns false. I think that could lead to racy conditions (even if, for the moment, I think that all is fine as the other pgstat_tracks_backend_bktype() calls should protect us). > And I guess that we're OK here, Yup. > so applied. Thanks! Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
