On Wed, Jun 22, 2022 at 12:28 AM Noah Misch <n...@leadboat.com> wrote: > "Everything" isn't limited to PostgreSQL. The Perl ABI exposes large structs > to plperl; a field of type double could require the AIX user to rebuild Perl > with the same compiler option.
Oh, that isn't so great, then. > Here's how I rank the options, from most-preferred to least-preferred: > > 1. Put new eight-byte fields at the front of each catalog, when in doubt. > 2. On systems where double alignment differs from int64 alignment, require > NAMEDATALEN%8==0. Upgrading to v16 would require dump/reload for AIX users > changing NAMEDATALEN to conform to the new restriction. > 3. Introduce new typalign values. Upgrading to v16 would require dump/reload > for all AIX users. > 4. De-support AIX. > 5. From above, "Somehow forcing values that are sometimes 4-byte aligned and > sometimes 8-byte aligned to be 8-byte alignment on all platforms". > Upgrading to v16 would require dump/reload for all AIX users. > 6. Require -qalign=natural on AIX. Upgrading to v16 would require dump/reload > and possible system library rebuilds for all AIX users. > > I gather (1) isn't at the top of your ranking, or you wouldn't have written > in. What do you think of (2)? (2) pleases me in the sense that it seems to inconvenience very few people, perhaps no one, in order to avoid inconveniencing a larger number of people. However, it doesn't seem sufficient. If I understand correctly, even a catalog that includes no NameData column can have a problem. Regarding (1), it is my opinion that the only real value of typalign is for system catalogs, and specifically that it lets you put the fields in an order that is aesthetically pleasing rather than worrying about alignment considerations. After all, if we just ordered the fields by descending alignment requirement, we could get rid of typalign altogether (at least, if we didn't care about backward compatibility). User tables would get smaller because we'd get rid of alignment padding, and I don't think we'd see much impact on performance because, for user tables, we copy the values into a datum array before doing anything interesting with them. So (1) seems to me to be conceding that typalign is unfit for the only purpose it has. Perhaps that's just how things are, but it doesn't seem like a good way for things to be. -- Robert Haas EDB: http://www.enterprisedb.com
