Thread

1. DEC Alpha initdb partial fix

   Dwayne Bailey <dwayne@mika.com> — 1998-03-16T11:51:11Z

   -----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@mika.com                 + What is your favorite color?
   http://www.mika.com/~dwayne     +    Blue ... no, Yelloooooooooooooooooow
               finger dwayne@mika20.mika.com for PGP Public Key
   
   -----BEGIN PGP SIGNATURE-----
   Version: 2.6.2
   
   iQB1AwUBNQ0SNqA2uleK7maRAQFnwwL9HaRnTmb0dWYUi6IarASXjNuGyijiNtVR
   j6Vtzi58HI/BtwKaFzwtbCj5koXIxVmm1Vu8IYUzS1S3T2gditcRR04i6QMYuLT6
   IYABZt38IWcmdbBJ+yVdYaZfE7tUECUv
   =jmf2
   -----END PGP SIGNATURE-----
   
   
   

2. Re: [HACKERS] DEC Alpha initdb partial fix

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-16T15:17:42Z

   > 
   > -----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
   
   Try the oid.c from 6.2.1.  I see no changes I can see in that code from
   6.2.1 -> 6.3, and we are told 6.2.1 worked for Alpha.  I believe this is
   our last big item in 6.3 open issues.
   
   Is the lack of index use in certain cases still true for some people?  I
   remember two people complaining about it.
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)