Re: [HACKERS] Re: [BUGS] Some BUG-FIXES to postgreSQL on SCO 3.2v5.0.2

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