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