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: Pine.OSF.3.95.980316063510.24568A-100000@mika20.mika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----

(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?
http://www.mika.com/~dwayne + Blue ... no, Yelloooooooooooooooooow
finger dwayne(at)mika20(dot)mika(dot)com for PGP Public Key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNQ0SNqA2uleK7maRAQFnwwL9HaRnTmb0dWYUi6IarASXjNuGyijiNtVR
j6Vtzi58HI/BtwKaFzwtbCj5koXIxVmm1Vu8IYUzS1S3T2gditcRR04i6QMYuLT6
IYABZt38IWcmdbBJ+yVdYaZfE7tUECUv
=jmf2
-----END PGP SIGNATURE-----

Responses

Browse pgsql-hackers by date

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