public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected]
Subject: Re: Decoupling our alignment assumptions about int64 and double
Date: Fri, 30 Jan 2026 23:46:08 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<6bfhumdtwrizt7iuujtgb7u2qdmyplhabg3glcvobw5vf7zst4@rrzhuxlrfojr>
	<[email protected]>
	<[email protected]>

I wrote:
> I think this might be about ready to go, unless somebody has
> a better idea than 'l' for the catalog representation of
> TYPALIGN_INT64.

I realized that there is more to consider here than we'd thought.
In particular, while we've mainly worried about what happens with
system catalog row layout, the change I've proposed here very
likely changes row layout in user tables, if we are on a platform
where TYPALIGN_INT64 != TYPALIGN_DOUBLE.  So this is a pg_upgrade
breaking change for such platforms.

Maybe this is another reason to decide that AIX isn't worth
re-supporting: if there are any AIX users out there who still care,
the prospect of a forced dump-and-reload might be enough to convince
them that they might as well migrate to a more modern platform while
they are at it.  Not sure.

If we do want to go forward with this, it would make sense to
adjust pg_control to store MAXALIGN, TYPALIGN_DOUBLE, and
TYPALIGN_INT64 separately, instead of

    /*
     * This data is used to check for hardware-architecture compatibility of
     * the database and the backend executable.  We need not check endianness
     * explicitly, since the pg_control version will surely look wrong to a
     * machine of different endianness, but we do need to worry about MAXALIGN
     * and floating-point format.  (Note: storage layout nominally also
     * depends on SHORTALIGN and INTALIGN, but in practice these are the same
     * on all architectures of interest.)
     *
     * Testing just one double value is not a very bulletproof test for
     * floating-point compatibility, but it will catch most cases.
     */
    uint32        maxAlign;        /* alignment requirement for tuples */
    double        floatFormat;    /* constant 1234567.0 */
#define FLOATFORMAT_VALUE    1234567.0

(Given that we've now pretty much locked in on IEEE float format,
I suspect floatFormat isn't pulling its weight anymore, but
perhaps that's a separate discussion.)

			regards, tom lane

view thread (2+ messages)

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]
  Subject: Re: Decoupling our alignment assumptions about int64 and double
  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