[postgis-users] PostGIS, 64 bit Solaris, Invalide memory alloc message using force_collection

[Stephen Woodbridge]

OK, Just for a reference point if it helps, I have built the following 
on 64bit Xeon system on Debian and it works fine, I can't say I have 
stress tested it, but I have dump and loaded various databases and 
performed various queries and updates without any issues.

"PostgreSQL 8.1.2 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5 
(Debian 1:3.3.5-13)"

"POSTGIS="1.1.0" GEOS="2.1.1" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS"

The int4 size problem you mentioned below could be benign on Intel 
because of the Endian-ness differences between Sparc and Intel.

-Steve W.

Michael Fuhr wrote:
> On Wed, Feb 01, 2006 at 01:01:41AM -0700, Michael Fuhr wrote:
> 
>>I have a Sparc running Solaris 9.  All of my PostgreSQL-related
>>apps are 32-bit but when I get a chance I'll see if I can build
>>64-bit versions of everything and do some testing.
> 
> 
> I've built 64-bit versions of PostgreSQL, GEOS, Proj, and PostGIS
> on Solaris 9/sparc.  Here's what I have:
> 
> PostgreSQL 8.1.2 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2
> POSTGIS="1.1.2CVS" GEOS="2.2.1-CAPI-1.0.1" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS
> 
> PostGIS is definitely having trouble with the 64-bit build.  Even
> simple operations fail:
> 
> gis=# select '00000000013FF00000000000004000000000000000'::geometry;
> ERROR:  Invalid type in wbk
> 
> I think part of the problem is the definition of int4 in
> lwgeom/lwgparse.c:
> 
> typedef unsigned long int4;
> 
> That makes int4 64 bits, which probably isn't what's intended.  Is
> there a reason not to simply include postgres.h and use PostgreSQL's
> definitions for int4, int32, etc.?  I commented out that line and
> included postgres.h and got a little farther:
> 
> gis=# select '00000000013FF00000000000004000000000000000'::geometry;
>                   geometry                  
> --------------------------------------------
>  00000000013FF00000000000004000000000000000
> (1 row)
> 
> gis=# select astext('00000000013FF00000000000004000000000000000');
>    astext   
> ------------
>  POINT(1 2)
> (1 row)
> 
> However, that doesn't fix everything.  SRIDs aren't being output,
> although apparently they are correctly parsed on input:
> 
> gis=# select geomfromewkt('SRID=4326;POINT(1 2)');
>                     geomfromewkt                    
> ----------------------------------------------------
>  0020000001000000003FF00000000000004000000000000000
> (1 row)
> 
> gis=# select asewkt(geomfromewkt('SRID=4326;POINT(1 2)'));
>       asewkt       
> -------------------
>  SRID=0;POINT(1 2)
> (1 row)
> 
> gis=# select srid(geomfromewkt('SRID=4326;POINT(1 2)'));
>  srid 
> ------
>  4326
> (1 row)
> 
> Here's another problem.  The input is MULTIPOINT(1 2); notice that
> the output is different:
> 
> gis=# select '00000000040000000100000000013FF00000000000004000000000000000'::geometry;
>                                                       geometry                                                      
> --------------------------------------------------------------------------------------------------------------------
>  00000000040000000400000000013FF0000000000000400000000000000000E000000E007027A800E000000F007027A800E000000F007027A8
> (1 row)
> 
> Calling geomfromtext('MULTIPOINT(1 2)') first thing in a new session
> gives this, which is wrong:
> 
> gis=# select geomfromtext('MULTIPOINT(1 2)');
>     geomfromtext    
> --------------------
>  000000000400000000
> (1 row)
> 
> Making the same query again gets even worse:
> 
> gis=# select geomfromtext('MULTIPOINT(1 2)');
> [over 2 million characters of output]
> 
> I'll keep poking around to see what I can find.
>