Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2 |
Дата | |
Msg-id | 199801112045.PAA08749@candle.pha.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
Applied with #if defined(sco) for 6.3. Beta testing Feb 1. > > You wrote: > > > > 2.) For the float8, it's required to edit the file > > > > > > ./src/include/utils/memutils.h > > > > > > #define DOUBLEALIGN(LEN) INTALIGN(LEN) > > > #define MAXALIGN(LEN) INTALIGN(LEN) > > > > > > Otherwise the backend will crash at the insertion of any float8. > > > > I am unsure why the existing code did not work. > > Sorry, I am sure. Let me try to convince you. > > I must quote the HTML version of the manual entitled as > "Programming Tools Guide Appendix A, ANSI implementation-defined > behavior". > > ****<Beginning of partial partial citation> > > This section describes the implementation-defined characteristics of > structures, unions, enumerations, and bit-fields. It corresponds to > section ``F.3.9 Structures, Unions, Enumerations, and Bit-Fields'' in > the ANSI document. > ........ > 80x86 does not impose a restriction on the alignment of objects; > any object can start at any address. However, for certain objects, > having a particular starting address can speed up processor access. > > The C compiler aligns the whole structure on a 4-byte boundary by > default (see ``Pragmas''). All [4|8|10]-byte objects are aligned on a > 4-byte boundary, 2-byte objects are aligned on a 2-byte boundary, while > 1-byte objects are not aligned. > > ****<End of citation> > > Now, it's clear: the *double* struct members will be aligned to a > *4-byte* address boundary (on SCO), but *the original code* computes > "DOUBLEALIGN" and "MAXALIGN" to a > *8-byte boundary*, because it defines the boundary of alignment as > *sizeof(double)* which is equal to 8 (on SCO). > This may lead to the "segmentation violation error", > which is only the consequence of a correct malloc (palloc) executed > after the corruption of administrative areas of malloc caused by > erroneous access of double struct members. (I have traced it.) > > Let me make some possibly unneccesary comments: > This type of assumptions is very "popular" in sytems originally > developed on other (BSD-derived or RISC-based) sytems. > The most popular form is the assumption about the behaviour of *malloc*: > it will align an malloc(sizeof(something)) to a *8-byte boundary*. > But it isn't the case. > Fortunately the postgreSQL not uses this assumption which holds > for your reference platform too. > > > Regards, > Tamas > _________________________________________ > Tamas Laufer > Voice/Fax: +36-72-447-570 > Email: lt660@ipisun.jpte.hu > H-7632 Pecs, Fulep L. u 26 III/11 Hungary > -- Bruce Momjian maillist@candle.pha.pa.us
В списке pgsql-hackers по дате отправления: