Re: [HACKERS] 64-bit hashjoins

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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+(at)CMU(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026