Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)

Hi,

On 2026-02-10 19:15:27 +0000, Bertrand Drouvot wrote:
> On Tue, Feb 10, 2026 at 01:15:01PM -0500, Andres Freund wrote:
> > On 2026-02-10 19:14:44 +0200, Heikki Linnakangas wrote:
> > Yea, I don't think we need to be perfect here. Just a bit less bad. And, as
> > you say, the current order doesn't make a lot of sense.
> > Just grouping things like
> > - pid, pgxactoff, backendType (i.e. barely if ever changing)
> > - wait_event_info, waitStart (i.e. very frequently changing, but typically
> > accessed within one proc)
> > - sem, lwWaiting, waitLockMode (i.e. stuff that is updated frequently and
> > accessed across processes)
>
> With an ordering like in the attached (to apply on top of Heikki's patch), we're
> back to 832 bytes.

You'd really need to insert padding between the sections to make it work...

> But, then the pg_attribute_aligned() added in Heikki's patch makes it 896 bytes...
>
> "
> /* 816 | 16 */ dlist_node lockGroupLink;
> /* XXX 64-byte padding */
>
> /* total size (bytes): 896 */
> }
> "
>
> What about applying this new ordering and remove the pg_attribute_aligned()?

> (I thought the aligned attribute would be smarter than that and not add this
> 64 padding bytes).

That's just because we have

/*
* Assumed cache line size. This doesn't affect correctness, but can be used
* for low-level optimizations. This is mostly used to pad various data
* structures, to ensure that highly-contended fields are on different cache
* lines. Too small a value can hurt performance due to false sharing, while
* the only downside of too large a value is a few bytes of wasted memory.
* The default is 128, which should be large enough for all supported
* platforms.
*/
#define PG_CACHE_LINE_SIZE 128

I don't think we need to worry about the number of bytes here very much. This
isn't much compared to all the other overheads a connection slot has (like the
memory for locks).

Greetings,

Andres Freund