On Wed, Jun 22, 2022 at 10:39 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > That's a fundamental misreading of the situation. typalign is essential > on alignment-picky architectures, else you will get a SIGBUS fault > when trying to fetch a multibyte value (whether it's just going to get > stored into a Datum array is not very relevant here).
I mean, that problem is easily worked around. Maybe you think memcpy would be a lot slower than a direct assignment, but "essential" is a strong word. > I concur that Noah's description of #2 is not an accurate statement > of the rules we'd have to impose to be sure that the C structs line up > with the actual tuple layouts. I don't think we want rules exactly, > what we need is mechanical verification that the field orderings in > use are safe. The last time I looked at this thread, what was being > discussed was (a) re-ordering pg_subscription's columns and (b) > adding some kind of regression test to verify that all catalogs meet > the expectation of 'd'-aligned fields not needing alignment padding > that an AIX compiler might choose not to insert. That still seems > like the most plausible answer to me. I don't especially want to > invent an additional typalign code that we could only test on legacy > platforms. I agree with that, but I don't think that having the developers enforce alignment rules by reordering catalog columns for the sake of legacy platforms is appealing either. -- Robert Haas EDB: http://www.enterprisedb.com