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

From Tom Lane
Subject Re: Decoupling our alignment assumptions about int64 and double
Date
Msg-id 1809799.1770407405@sss.pgh.pa.us
Whole thread Raw
In response to Re: Decoupling our alignment assumptions about int64 and double  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Decoupling our alignment assumptions about int64 and double
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> 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.

I experimented with that.  It's spelled -malign-natural, and it
does change ALIGNOF_DOUBLE from 4 to 8.

> Of course
> that might create ABI problems for structs in library headers,

Yeah, that.  Perhaps we'd get away with it, but I think Andres'
suggestion of putting an alignment spec into typedef float8
has a far smaller blast radius.  (I tested that too, and it
seems to work.)

Side observation: either approach sets ALIGNOF_DOUBLE = 8 in both
32-bit and 64-bit builds, while ALIGNOF_INT64_T is 8 in any case.
I still think we should deprecate 32-bit AIX builds because of the
hassles around finding address space for loadable modules; but
the data alignment situation isn't different.

Of course the $64 question is whether we can get away with requiring a
dump and reload (and how we'd make pg_upgrade enforce that if we did,
considering that existing installations' pg_control will only surface
the value of MAXALIGN not DOUBLEALIGN).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Next
From: Andrew Dunstan
Date:
Subject: Re: [PING] fallocate() causes btrfs to never compress postgresql files