Tom, you fixed this, right?
> 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
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
