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

DEC Alpha initdb partial fix

From: Dwayne Bailey <dwayne(at)mika(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: DEC Alpha initdb partial fix
Date: 1998-03-16 11:51:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

(I lost a block of mail a while back, so if this is 'old hat,',
please let me know)

Well, my eyes are about crossed, but I believe that I've found
PART of the problem with initdb in 6.3 on the DEC Alpha.  (I'm
running Digital Unix 3.2, rather than 4.0, but I don't think that
makes a difference.)  This does NOT fix the problem, but I
believe that it moves us closer.  I'm hoping that this will
trigger somebody else to know where else to look.

In backend/utils/adt/oid.c, the routine oid8in() makes the
assumption that an Oid is the same size as a pointer.  Actually,
I'm not quite sure why this code was written this way at all.  It
declares an array of pointers to Oids, and then fills in the
pointers with the actual Oids.  Sorry I can't provide a true
diff output at this time - the code is too hacked up.  Simply
replacing '*result' with 'result' throughout the routine, except
on the declaration, which should be

	Oid	*result;
rather than
	Oid	(*result)[];

And then changing the cast of the palloc accordingly takes care
of this invalid assumption.

I found this because I was attempting to do a lookup of
'mkoidname' explicitly, much earlier in the run than when
specified in the input file.  It failed.  I could lookup up
int4in or int4out, but not mkoidname, even when I set all keys
explicitly.  With this fix, the explicit lookup works correctly.
However, it still fails during index creation, where it's
actually used.  This is because the Oid of attrelid and attname
are both being returned as 0, rather than 26 and 19,
respectively.  With a hack to 'hard code' those values in the
lookup routine, the mkoidname lookup passes.  (The index is
still not created, however.  It does later.)

I'm still trying to find other instances where this assumption has
been made.  As an interim solution, I'm experimenting with using
the -xtaso_short flag to DEC's cc compiler, which supposedly
tells it to generate only 32-bit pointers.  This of course won't
fix the problems, but it may get 6.3 functional on Alphas.

- --
Dwayne Bailey                   + WHAT is your name? Sir Galahad
MIKA Systems, Bingham Farms, MI + WHAT is your quest? I Seek the Holy Grail
dwayne(at)mika(dot)com                 + What is your favorite color?     +    Blue ... no, Yelloooooooooooooooooow
            finger dwayne(at)mika20(dot)mika(dot)com for PGP Public Key

Version: 2.6.2



pgsql-hackers by date

Next:From: Mattias KregertDate: 1998-03-16 12:20:03
Subject: Re: [DOCS] Re: [HACKERS] Small changes for the "no excuses" release
Previous:From: Luuk de BoerDate: 1998-03-16 11:16:21
Subject: Re: [QUESTIONS] MySQL benchmark page

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