Well I've moved forward and now have code in production calculating mileages from OpenStreetMap data: I've calculated mileage charts for Oceania and Africa. <br>The secret to get that far was to move operating systems from Windows to Ubuntu and then upgrade to pgRouting 1.05. (PostGres 8.4, Ubuntu 10)<br>
Th computations are being performed with dijkstra_sp_delta.<br><br>However now I'm hitting another "server closed the connection unexpectedly" error.<br><br>Looking in the server logs, I find the LOG message "server process (PID 19133) was terminated by signal 6: Aborted"<br>
>From what I can tell, Signal 6 on Ubuntu is indeed a SIGABRT. There are no other log messages to indicate why Postgres/pgRouting threw a SIGABRT.<br>
<br>
This is then followed by warnings and log messages saying other
active server processes are being terminated, transactions rolled back,
etc.<br>
<br>
This error occurs at a reproducible point in a fairly sophisticated (multi-processor, Python, psycopg) script. Although I'm pretty certain of the SQL that is causing the problem, at the moment I don't have the exact parameters (ie. graph nodes). I'm about to run the script single-threaded with diagnostics so I should be able to get a single SQL statement to reproduce the problem on a psql command line. In the worst case, this could take a couple of days.<br>
No other programs are running that are calling Postgres.<br><br>My graph consists of the global OSM street data loaded into PostGIS with osm2po. I have checked for links of zero length. In fact all links <1m long have been taken out of the graph. I've just double checked costs and reverse_costs: all are positive (I've set these to the lengths)<br>
<br>I've just checked for start & end nodes being the same (ie. resulting in dijkstra_sp_delta being called with the some node identifier for the start and end): Yes my data has a few of these, but I'm pretty certain the crash occurs before they appear. However, I'm going to add code to detect these - there's no point in executing an SQL statement for something that can be calculated in a trivial line of python.<br>
<br>What else should I be looking for? Are there any known problems I should look for? Is there any way of finding out what is causing the Signal 6?<br><br>Once I have the node identifiers that are causing the problem, I should be able to make en exportable-extract of the graph to give a reproducible dataset and matching SQL statement. Would anyone be able to investigate this?<br>
<br>Is there any way of making pgRouting / PostGres handle these situations more cleanly? At the moment, the crash is taking the server down with it. The crash is perhaps the first to occur after roughly 1 million route calculations: I can live with that failure rate - but only if my scripts can cleanly detect and recover from it. I guess ideally the server should stay up and a status value (or exception - but that probably wouldn't work across so many code boundaries) be returned.<br>
<br><br><br>Best regards,<br><br><br>Richard Marsden<br><br>