Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2026-02-22T11:15:03Z
Lists: pgsql-hackers
On 21/02/2026 11:42, Bertrand Drouvot wrote: > On Fri, Feb 20, 2026 at 11:03:09PM +0200, Heikki Linnakangas wrote: >> On 11/02/2026 06:40, Bertrand Drouvot wrote: >>> That looks ok to see PGPROC as an "acceptable" one, if not, should we use the >>> union trick? >> >> It seems acceptable to just not align it if the compiler doesn't support it. >> This is just a performance optimization, after all. > > Agreed. > >> Attached is new versions the remaining patches. I think these are ready to >> be committed. > > Thanks! > > One nit, 0001 is adding the typedef: > > " > -struct PGPROC > +typedef struct PGPROC > . > . > . > -}; > - > -/* NOTE: "typedef struct PGPROC PGPROC" appears in storage/lock.h. */ > + uint32 wait_event_info; /* proc's wait information */ > +} PGPROC; > " > > Would that make more sense to add the typedef when we introduce the explicit > alignment in 0002 (like it was done in your previous > v2-0001-Align-PGPROC-to-cache-line-boundary.patch up-thread)? Yeah, I had it as part of the other commit in the previous version, but decided to make it part of the other one, so that it's more clear what the alignment. I don't think it matters much either way though. Pushed, thanks for the review! - Heikki
Commits
-
Use C11 alignas in typedef definitions
- 5c2a8d272b9a 19 (unreleased) landed
-
Align PGPROC to cache line boundary
- 412f78c66eed 19 (unreleased) landed
-
Rearrange fields in PGPROC, for clarity
- 2e0853176f8f 19 (unreleased) landed
-
Split PGPROC 'links' field into two, for clarity
- 36bbcd5be3ff 19 (unreleased) landed
-
Remove useless store to local variable
- ab32a9e21d37 19 (unreleased) landed
-
Separate RecoveryConflictReasons from procsignals
- 17f51ea81875 19 (unreleased) cited