<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">As a follow up to my previous email, <div><br></div><div><br></div><div>I created a new routing table containing the edges that would have been considered in my previous query (on the entire USA). Then ran assign_vertix_id() to rebuild the source/target ids, and issued the same query with success. </div><div><br></div><div>This seems to indicate that the source, target and/or id fields are too large in my USA level routing table. This goes inline with this ticket, which has the same error I encountered on my previous 32 bit instance: <a href="http://download.osgeo.org/pgrouting/forum/pgrouting.postlbs.org/ticket/149.html">http://download.osgeo.org/pgrouting/forum/pgrouting.postlbs.org/ticket/149.html</a></div><div><br></div><div><br></div><div>Cheers,</div><div>Ben</div><div><br><div><div>On 2010-12-11, at 9:54 PM, Ben Brehmer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br></div><div>Currently attempting to get PgRouting to work on a USA dataset. I have created the routing table (source, target, id, the_geom etc) with osm2po as all other routing converters (ie. osm2pgrouting) failed due to out of memory. Currently I am attempting to run a shortest_path_astar query. The result is a crashed Database and the following Postgres log: </div><div><br></div><div><div><i>terminate called after throwing an instance of '<b>std::bad_alloc</b>'</i></div><div><i> what(): <b>St9bad_alloc</b></i></div><div><i>LOG: server process (PID 1170) was terminated by signal 6: Aborted</i></div><div><i>LOG: terminating any other active server processes</i></div><div><i>FATAL: the database system is in recovery mode</i></div><div><i>LOG: all server processes terminated; reinitializing</i></div><div><i>LOG: database system was interrupted; last known up at 2010-12-12 05:17:42 UTC</i></div><div><i>LOG: database system was not properly shut down; automatic recovery in progress</i></div><div><i>LOG: <b>record with zero length at 1F/FCF370A8</b></i></div><div><i>LOG: redo is not required</i></div></div><div><br></div><div><br></div><div>I suspect my data may be the problem as it is all of USA (from Cloudmade OSM file). My max source/target ids are quite large:</div><div>Max source/target id: 25,638,274</div><div><br></div><div>I have confirmed length and valid geometries on all rows in my sample query. I have confirmed valid source/target/ids on all rows in test query. </div><div><br></div><div>Without being a knowledgable C programmer, how would you suggest I go about debugging this? I have tried changing 'int' types in a_star.c to 'long' types, without luck. Without setting up an entire C development environment, is there a way to add debug statements to the C code (and then re-compile)? Tried increasing Postgres logging to the Maximum (debug5) and didn't receive any more useful information.</div><div><br></div><div><br></div><div>Any help is greatly appreciated! For more detailed system info, please read below.</div><div><br></div><div>Thanks!</div><div><br></div><div>Ben</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>Currently running on a 64 bit amazon (Large instance):</div><div><i>Linux version 2.6.34.7-56.40.amzn1.x86_64 (<a href="mailto:mockbuild@build-31005.build">mockbuild@build-31005.build</a>) (gcc version 4.4.4 20100525 (Red Hat 4.4.4-5) (GCC) ) #1 SMP Fri Oct 22 18:48:49 UTC 2010</i></div><div><br></div><div>Also tried the Amazon 32 bit Linux instance (Small instance type) and received a "<i>std::length_error, vector::_M_fill_insert</i>" error:</div><div><i>Linux version
2.6.34.7-56.40.amzn1.i686 (<a href="mailto:mockbuild@build-31003.build">mockbuild@build-31003.build</a>) (gcc version
4.4.4 20100525 (Red Hat 4.4.4-5) (GCC) ) #1 SMP Fri Oct 22 18:48:33 UTC
2010</i></div><div><br></div><div>Tried both Pgrouting 1.05 and 1.04. </div><div><br></div><div>I am running Postgres 8.4, PostGIS 1.5 as follows:</div><div><i>#select version();</i></div><div><div><i> version </i></div><div><i>------------------------------------------------------------------------------------------------------------------</i></div><div><i> PostgreSQL 8.4.5 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit</i></div></div><div><i><br></i></div><div><i>#select postgis_version();</i></div><div><div><i> postgis_version </i></div><div><i>---------------------------------------</i></div><div><i> 1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1</i></div></div><div><br></div><div>Sample Query:</div><div><br></div><div><div>SELECT * FROM shortest_path_astar(' </div><div> SELECT</div><div> roads.osm_id as id, roads.source::integer AS source, roads.target::integer AS target, (CASE WHEN roads.cost =0 THEN 1 ELSE roads.cost END)::float8 AS cost, roads.x1, roads.y1, roads.x2, roads.y2 </div><div> FROM </div><div> ways roads</div><div> WHERE </div><div> (the_geom && ST_Expand(ST_SetSRID(ST_MakeBox2d(ST_Point(-73.945798873896,40.644763731167), ST_Point(-73.955540657038,40.649745616898)),4326), 0.01) )</div><div> ', 42479854, 42497359, false, false) route ;</div></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></blockquote></div><br></div></body></html>