Re: [HACKERS] DEC Alpha initdb partial fix
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] DEC Alpha initdb partial fix |
Дата | |
Msg-id | 199803161517.KAA08433@candle.pha.pa.us обсуждение исходный текст |
Ответ на | DEC Alpha initdb partial fix (Dwayne Bailey <dwayne@mika.com>) |
Список | 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 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)
В списке pgsql-hackers по дате отправления: