Re: [HACKERS] 64-bit hashjoins - Mailing list pgsql-hackers

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Tom, you fixed this, right?

I believe this is fixed, but it'd be nice to have some confirmation from
someone with a platform where long != int ...  Erik, have you tried it
recently?
        regards, tom lane


>> 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, Pennsylvania 19026