Ok, I just commited changes, pls, check it on HPPA.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I suggest to replace bytea by struct
> typedef struct {
> int32 n; /* number of GISTENTRY */
> GISTENTRY vector[1];
> } GistEntryVector;
Yes, I was thinking the same thing.
> #define GEVHDRSZ (MAXALIGN(sizeof(int32))
> so, allocation
I suppose that a correct fix involves doing MAXALIGN(VARDATA(evec)),
but I do not know what places need to change to support this.
Its only union and picksplit user-defined methods in contrib modules.
If I recall correctly, we decided to go with the present hack because we
found the problem jus
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> But all of this is strage for me, because we already faced to problem with
> 8-bytes strict aliasing in GiST code, and we had resolved problem on Sun and
> Alpha boxes. What was it changed?
It looks to me like the HP compiler is expecting that the cons
Tom Lane wrote:
I've just found out the hard way that Postgres doesn't even build on
recent gcc releases for 64-bit HPPA. The reason is that the compiler
now notices and complains about alignment errors that will lead to
core dump at runtime, and GIST has got some. The particular code that
fails
I've just found out the hard way that Postgres doesn't even build on
recent gcc releases for 64-bit HPPA. The reason is that the compiler
now notices and complains about alignment errors that will lead to
core dump at runtime, and GIST has got some. The particular code that
fails to compile is in
