Erik Riedel <riedel+@CMU.EDU> writes:
> Platform: Alpha, Digital UNIX 4.0D
> [ memutils.h says ]
> /*
> * even though "long alignment" should really be on 8-byte boundaries for
> * linuxalpha, we want the strictest alignment to be on 4-byte (int)
> * boundaries, because otherwise things break when they try to use the
> * FormData_pg_* structures. --djm 12/12/96
> */
I remember looking at that code and saying "Huh? You can't do that!".
I kept my fingers off it because I didn't have direct proof that it
was broken ... but it sounds like you do.
> Can someone explain the comment from djm to me (or is djm still
> listening somewhere?). At first blush, I suspect that I actually
> _want_ it to do the latter version of LONGALIGN(), since my longs
> really are 8 bytes. But when I try to do that instead, I am unable to
> even run "initdb" - dies with an error like "attribute not
> found/invalid"
Yeah, that's about what I'd expect. The point is that the struct
layouts found in include/catalog/pg_*.h for system table records
have to match the actual physical layout of tuples on disk. What
you are probably running into is that the attribute size/alignment
calculations done by the heaptuple code using the declared column data
types fail to match up with the struct field alignment done by the
compiler.
My guess is that either a struct field is being declared "long" when
it really oughta be "int", or some part of the tuple storage routines
is applying LONGALIGN() when it only oughta apply INTALIGN(). This
is something that would be difficult to track down or verify without
a box on which sizeof(int) != sizeof(long), so I haven't gone after it.
If you have time, please leave memutils.h with the more reasonable
looking definition of LONGALIGN() and go looking to find out which
system table has the sizing conflict.
BTW, we'd run into this same problem if any of the system tables had
a float8 column, since the alignment of those is platform-dependent.
Memo to hackers: stay away from float8 in sys tables.
regards, tom lane
