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

On 10/02/2026 21:46, Andres Freund wrote:
> 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...

Here's my attempt at grouping things more logically. I didn't insert
padding and also didn't try to avoid alignment padding. I tried to
optimize for readability rather than size or performance. That said, I
would assume that grouping things logically like this would also help to
avoid false sharing. If not, inserting explicit padding seems like a a
good fix.

I also think we should split 'links' into two fields. For clarity.

With this, sizeof(PGPROC) == 864 without the explicit alignment to
PG_CACHE_LINE_SIZE, and 896 with it.

- Heikki