Re: [HACKERS] 64-bit hashjoins
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] 64-bit hashjoins |
Дата | |
Msg-id | 199905100435.AAA23320@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] 64-bit hashjoins (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] 64-bit hashjoins
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: