Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2026-03-16T10:42:35Z
Lists: pgsql-hackers
On 24.02.26 12:28, Bertrand Drouvot wrote: >> You can/should use C11 standard alignas(), so you don't need to worry about >> whether it's supported or not. > > Oh right, I did not notice 300c8f53247 and following like e7075a3405c, d4c0f91f7d5 > and 97e04c74bed. > > PFA, 0001 doing so for PGPROC and PgAioUringContext. As those are typedef, > the patch puts alignas within the struct. > > For PGPROC at the start of the struct, I think that placing it on the first member > is the right location because it ensures the whole struct is aligned to PG_CACHE_LINE_SIZE > without adding padding before this member. For example if I set it on backendType, > then it adds 100 bytes of padding and the struct is obviously still a multiple of > PG_CACHE_LINE_SIZE but is now 1024 bytes (instead of 896). > > For PgAioUringContext at completion_lock (like suggested by Andres in [1]), which > is also the start of the struct. > > I checked and the padding for those are exactly the same after the changes. I have committed the 0001 patch. > 0002, is also making use of alignas in ItemPointerData, but this one is more > tricky so I'm not sure that's worth it (given the fact that we still need to > keep pg_attribute_aligned() as explained by Peter in [2]). This doesn't seem worth it to me. Let's skip it.
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