Re: Decoupling our alignment assumptions about int64 and double

Thomas Munro <thomas(dot)munro(at)gmail(dot)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