Thread

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

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-11T20:45:23Z

    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