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

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Date: 2026-03-16 10:42:35
Message-ID: 3ff35999-7a1e-40fa-938c-f2bff85e2e2f@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2026-03-16 10:56:24 pgsql: Fix pg_upgrade failure when extension_control_path is used
Previous Message Peter Eisentraut 2026-03-16 09:54:06 pgsql: Prevent -Wstrict-prototypes and -Wold-style-definition warnings

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-03-16 10:56:00 Re: Skipping schema changes in publication
Previous Message Alena Rybakina 2026-03-16 10:33:14 Re: Vacuum statistics