Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Date
Msg-id f7d3fd76-330f-488b-8f2e-722796127ae0@iki.fi
Whole thread Raw
In response to Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Comment for UserMappingPasswordRequired in contrib/postgres_fdw
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication