public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bertrand Drouvot <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Date: Mon, 16 Mar 2026 11:16:51 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<aY7auF2/[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

On Mon, Mar 16, 2026 at 11:42:35AM +0100, Peter Eisentraut wrote:
> 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.

Thanks! I don't know why but I don't see it in https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary,
or in the github repo though.

> > 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.

Yeah, that makes sense.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox