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

From Andres Freund
Subject Re: Decoupling our alignment assumptions about int64 and double
Date
Msg-id 2krmsgtgwtzauvolorina2xb2hu64thttutspd4yilsstypakm@gvtlwtdt2b7h
Whole thread Raw
In response to Re: Decoupling our alignment assumptions about int64 and double  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Decoupling our alignment assumptions about int64 and double
List pgsql-hackers
Hi,

On 2026-02-03 17:29:46 -0500, Tom Lane wrote:
> I wrote:
> > Attached a v3 of the main patch (now again numbered 0001), plus
> > new work in 0002 that adds the two new alignment values to
> > pg_control and insists on a match before pg_upgrade'ing.
> 
> I've gotten cold feet about this whole idea, and no longer think
> we should pursue it.  Aside from the problems already raised,
> consider this: what would extensions do with existing int64-based
> data types?  We don't have any provision for altering the typalign
> of an existing type, and if we did it would imply doing table
> rewrites (at least for cases where the change wasn't effectively
> a no-op).  Worse, if such a type is created using "LIKE int8"
> which has always been best practice, then whether it shows up
> with align 'l' or 'd' in a new installation will depend on whether
> you pg_upgrade'd or installed the extension fresh.  So that looks
> like a mess waiting to happen.  Combine that with extensions that
> manually set alignment = double, and never bother to update because
> they can't change it and don't care anyway, and the inevitable end
> result is that the 'l' and 'd' cases will be so randomly assigned
> that there's not a meaningful difference after all.  Perhaps we
> could have got away with such a change in the pre-pg_upgrade era,
> but I think we cannot now.

I can't really see a way to avoid these issues either :(


> If we want to re-support AIX, I think we're stuck with going back
> to the old way of calculating MAXALIGN, and then re-instituting that
> regression test that checked for unsafely-aligned catalog columns.
> Bleah.  Still, as long as the regression test is accurate, it seems
> like that'd be an annoyance not a major headache.

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

#if ALIGNOF_DOUBLE < ALIGNOF_LONG
typedef double __attribute__((aligned(8))) float8;
#define ALIGNOF_FLOAT* ALIGNOF_LONG
#else
typedef double float8;
#define ALIGNOF_FLOAT8 ALIGNOF_DOUBLE
#endif


should do the trick.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: pg_upgrade: transfer pg_largeobject_metadata's files when possible
Next
From: Peter Smith
Date:
Subject: Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0