Re: [HACKERS] Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2 |
Дата | |
Msg-id | 199801112045.PAA08757@candle.pha.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
Again, installed in 6.3. > > This is a SCO problem report. > > It seems the alignment macros do not work on SCO because a malloc(8) is > aligned on a 4-byte boundary on SCO, and not an 8-byte boundary as > assumed by our alignment code. > > I always thought that memory would be malloc'ed to align with the size > of the request, but SCO doesn't do that. > > Would people please look at memutils.h and tell me what to do? We have > some fairly complex alignment stuff ifdef'ed out at the top of the file, > and some simpler stuff used in its place. > > > > > 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 > > -- Bruce Momjian maillist@candle.pha.pa.us
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: [PATCHES] Patches for getting version 6.2/6.2.1 running on