Обсуждение: DEC Alpha initdb partial fix

Поиск
Список
Период
Сортировка

DEC Alpha initdb partial fix

От
Dwayne Bailey
Дата:
-----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-----


Re: [HACKERS] DEC Alpha initdb partial fix

От
Bruce Momjian
Дата:
>
> -----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)