Re: [HACKERS] 64-bit hashjoins

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Erik Riedel <riedel+(at)CMU(dot)EDU>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] 64-bit hashjoins
Date: 1999-05-10 04:35:24
Message-ID: 199905100435.AAA23320@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom, you fixed this, right?

> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-05-10 04:53:13 Re: [HACKERS] INSERT INTO
Previous Message Hiroshi Inoue 1999-05-10 01:24:15 RE: [HACKERS] 6.5 beta and ORDER BY patch