Re: [HACKERS] 64-bit hashjoins

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