Re: Decoupling our alignment assumptions about int64 and double - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Decoupling our alignment assumptions about int64 and double
Date
Msg-id CA+hUKG+2qt7Wz7knqC49OkqAGv4+F5+AykLVJpOwx7ChqU-mSg@mail.gmail.com
Whole thread Raw
In response to Re: Decoupling our alignment assumptions about int64 and double  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Feb 6, 2026 at 12:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2026-02-03 17:29:46 -0500, Tom Lane wrote:
> > I am pretty unhappy about that, I think the test and rules are just about
> > incomprehensible. I wonder if we ought to instead just redefine float8 to be
> > be aligned to 8 bytes, leaving double alone.
>
> I thought about that, but it seemed like there'd be nothing stopping
> people from declaring a catalog column as "double" rather than
> "float8" and thus falling into the trap anyway.  I suppose we could
> put a check for that into Catalog.pm, though.

I see that pg_upgrade is the real problem, but if that's somehow OK
("v19 is a new port, dump and restore needed!") then I wonder if
-malign=natural (which seems to be the GCC equivalent of what the
native compiler called -qalign=natural) might be an option.  Of course
that might create ABI problems for structs in library headers, IDK,
but I recall that it's not uncommon for software to tweak that sort of
thing on AIX so I wonder if system headers might have their own
alignment attributes to cope... and if some third party library breaks
(how many libraries actually deal in double though?), I wonder if it's
possible to pragma/push/whatever your way around it...



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: Make wal_receiver_timeout configurable per subscription
Next
From: Ashutosh Bapat
Date:
Subject: Re: relkind as an enum