Re: AIX support - alignment issues
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-06T17:17:24Z
Lists: pgsql-hackers
On Wed, Jul 6, 2022 at 12:27 PM Andres Freund <andres@anarazel.de> wrote: > I think my proposal of introducing a version of double that is marked to be 8 > byte aligned should do the trick as well, and doesn't have the problem of > changing the meaning of 'double' references in external headers. In fact, we > already have float8 as a type, so we could just add it there. Yeah, but how easily will it be to know whether we've used that in every relevant place? Could we insist on 8-byte alignment even on 32-bit platforms? I think we have a few of those in the buildfarm, so maybe that would help us spot problems. Although I'm not sure how, exactly. > The problem with having a lot more alignment values is that it adds a bunch of > overhead to very performance critical paths. We don't want to add more > branches to att_align_nominal() if we can avoid it. Fair. > I'm fairly certain that we're going to add a lot more 64bit ints to catalogs > in the next few years, so this will become a bigger issue over time... Absolutely. > Outside of the catalogs I still think that we should work towards not aligning > byval values (and instead memcpy-ing the values to deal with alignment > sensitive platforms), so we don't waste so much space. And for catalogs we've > been talking about giving up the struct mapping as well, in the thread about > variable length names. In which case we could the cost of handling more > alignment values wouldn't be incurred as frequently. +1. Aligning stuff on disk appears to have few redeeming properties for the amount of pain it causes. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Doc: Acknowledge historically supported CPUs and OSes.
- 14168d3c62fa 16.0 landed
-
Further tidy-up for old CPU architectures.
- 718aa43a4ee6 16.0 landed
-
Tidy up claimed supported CPUs and OSes.
- 92d70b77ebb4 16.0 landed
-
Remove HP/Intel Itanium support.
- 0ad5b48e5894 16.0 landed
-
Remove HP-UX port.
- 9db300ce6e38 16.0 landed
-
Reorder subskiplsn in pg_subscription to avoid alignment issues.
- 79b716cfb7a1 15.0 cited
-
Tighten TAP tests' tracking of postmaster state some more.
- 4fdbf9af5184 15.0 cited
-
Reorder pg_sequence columns to avoid alignment issue
- f3b421da5f4a 10.0 cited