Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] 64-bit hashjoins

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Erik Riedel <riedel+(at)CMU(dot)EDU>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] 64-bit hashjoins
Date: 1999-03-24 23:52:56
Message-ID: 27282.922319576@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Erik Riedel <riedel+(at)CMU(dot)EDU> writes:
>    1 elog(fmt = 0x1400067b0 = "create index: type for attribute '%s'
> undefined") ["elog.c":224, 0x12016e530]
>    2 NormIndexAttrs(attList = 0x8fc, attNumP = 0x1401e91e2, classOidP =
> 0x1401e91f8) ["indexcmds.c":500, 0x12007ae5c]

> Does this help identify where to look?

Just from looking at that chunk of the source, it seems that the problem
is in either pg_type or pg_attribute, since it is using a field from a
pg_attribute tuple to look for a pg_type tuple... probably
pg_attribute... which starts out with
    Oid         attrelid;
    NameData    attname;
    Oid         atttypid;
Could it be NameData?  A few minutes later: YUP!

>From pg_type, type "name" is declared as having fixed length 32 and
int-alignment (typalign = 'i').  This is dubious enough, since a
compiler is likely to treat a char array as having only byte alignment;
typalign = 'c' seems more correct.  But it's been working so far and
prolly wouldn't break on an Alpha.

But in src/include/access/tupmacs.h we find the code that actually
implements attribute alignment calculations, and it reads:

#define att_align(cur_offset, attlen, attalign) \
( \
    ((attlen) < sizeof(int32)) ? \
    ( \
        ((attlen) == -1) ? \
        ( \
            ((attalign) == 'd') ?   DOUBLEALIGN(cur_offset) : \
                                    INTALIGN(cur_offset) \
        ) \
        : \
        ( \
            ((attlen) == sizeof(char)) ? \
            ( \
                (long)(cur_offset) \
            ) \
            : \
            ( \
                AssertMacro((attlen) == sizeof(short)), \
                SHORTALIGN(cur_offset) \
            ) \
        ) \
    ) \
    : \
    ( \
        ((attlen) == sizeof(int32)) ? \
        ( \
            INTALIGN(cur_offset) \
        ) \
        : \
        ( \
            AssertMacro((attlen) > sizeof(int32)), \
            ((attalign) == 'd') ?   DOUBLEALIGN(cur_offset) : \
                                    LONGALIGN(cur_offset) \
        ) \
    ) \
)

Walk through that with attlen = 32, attalign = 'i', and guess what:
it applies LONGALIGN().  Which is different on Alpha than everywhere
else, not to mention flat-out wrong for the given arguments.

Erik, try changing that last LONGALIGN to INTALIGN and see if it
works any better on the Alpha.

We probably really ought to bag this entire logic and replace it
with something like
		attalign 'c' -> no alignment
		attalign 's' -> SHORTALIGN
		attalign 'i' -> INTALIGN
		attalign 'd' -> DOUBLEALIGN
with possibly some AssertMacro cross-checks that the given attlen
makes sense for the attalign.  But driving the logic primarily off
attlen rather than attalign makes little sense to me.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: TaralDate: 1999-03-25 01:11:13
Subject: Re: [HACKERS] static oid
Previous:From: RHS Linux UserDate: 1999-03-24 19:55:21
Subject: Re: [HACKERS] Really slow query on 6.4.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group