Haven't finished analyzing the situation yet, but don't think its bad RAM as I had originally suspected.
The reason is as follows 1) If I take this original good table -- restore it on a PostGIS 1.4 database on the same server and repeat the copy process, it works fine. 2) Restoring it on their production server (different server), which is a 1.3.6 and then repeating the process gives the same problem. This database is a backup of their production database, so could be some corruption in the original production. So next step is to create a clean 1.3.6 database on this dev server and repeat the process to rule out 1.3.6 as the culprit. Hope to get around to doing that sometime today. Thanks, Regina -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ben Madin Sent: Monday, February 08, 2010 8:21 AM To: PostGIS Users Discussion Cc: 'PostGIS Development Discussion' Subject: Re: [postgis-users] [postgis-devel] Has anyone seen this before? Mark, On 08/02/2010, at 17:10 , Mark Cave-Ayland wrote: > Paragon Corporation wrote: > >> It should be noted that for this table the_geom is the first field in >> the table and addr_num_tlid comes right after and is a varchar I can >> select any integer or bigint field fine, but selecting any text or >> varchar field results in the ERROR: invalid memory alloc request >> size 18446744073709551613 > > Yup, this is totally wrong. I suspect bad RAM and/or disk on the machine in question. For only my own benefit possibly, but is this because the geometry column is being stored outside the normal table pages (the TOAST bit)? cheers Ben _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
