psycopg2.InterfaceError: connection already closed / pgr_astar

Question

I am using psycopg2 to access a postgresql database from python. When I try to run the pgrouting function "pgr_astar" for the shortest path, I receive an error

cur = db.cursor()
psycopg2.InterfaceError: connection already closed

Basically, what happened is: when pgr_astar does not find a path between two points, it creates a crash of the database, and it closes the connection to the database.

How is it possible to avoid this?

I tried to isolate the function with a try/except and to create its own connection, so no problem if it closes:

conn = psycopg2.connect(...)
try:
    result = getRecords(conn,query_pgr_astar)
    return float(result[0]['sum'])
except:
    return 500000000.0
conn.close()

But in this case I receive a

cur.execute(query)
psycopg2.DatabaseError: SSL SYSCALL error: EOF detected

How is it possible to manage impossible paths?

(I did the same with pgdb and the old shortest_path_astar function (not available to me anymore), and I had no problem)

Postgresql log is:

2013-11-27 15:54:35 CET LOG:  terminating any other active server processes
2013-11-27 15:54:35 CET WARNING:  terminating connection because of crash of another server process
2013-11-27 15:54:35 CET DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2013-11-27 15:54:35 CET HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2013-11-27 15:54:35 CET WARNING:  terminating connection because of crash of another server process
2013-11-27 15:54:35 CET DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2013-11-27 15:54:35 CET HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2013-11-27 15:54:35 CET LOG:  all server processes terminated; reinitializing
2013-11-27 15:54:35 CET LOG:  database system was interrupted; last known up at 2013-11-27 15:42:01 CET
2013-11-27 15:54:35 CET LOG:  database system was not properly shut down; automatic recovery in progress
2013-11-27 15:54:35 CET LOG:  record with zero length at 65/80875D60
2013-11-27 15:54:35 CET LOG:  redo is not required
2013-11-27 15:54:35 CET LOG:  autovacuum launcher started
2013-11-27 15:54:35 CET LOG:  database system is ready to accept connections

The query I do is:

SELECT SUM(t2.length) FROM (SELECT id2 FROM pgr_astar('SELECT edge_id AS id, vertex_id1 AS source, vertex_id2 AS target, ' || '(CASE WHEN door = ''S'' THEN -1.0  ELSE  (length * (CASE network WHEN ''0'' THEN 1.0  WHEN ''10'' THEN 1.2  WHEN ''20'' THEN 1.5  WHEN ''30'' THEN 2.0  ELSE 1.0  END) *  (CASE type WHEN ''9.1'' THEN CASE WHEN level1 < level2 THEN 3.0 ELSE 2.0 END  WHEN ''9.2'' THEN CASE WHEN level1 < level2 THEN 15.0 ELSE 12.0 END  ELSE 1.0  END) +  (CASE type WHEN ''9.3'' THEN 40.0  ELSE 0.0  END)  )  END)::float8 AS cost, ' || '(CASE WHEN door_rev = ''S'' THEN -1.0  ELSE  (length * (CASE network WHEN ''0'' THEN 1.0  WHEN ''10'' THEN 1.2  WHEN ''20'' THEN 1.5  WHEN ''30'' THEN 2.0  ELSE 1.0  END) *  (CASE type WHEN ''9.1'' THEN CASE WHEN level1 < level2 THEN 3.0 ELSE 2.0 END  WHEN ''9.2'' THEN CASE WHEN level1 < level2 THEN 15.0 ELSE 12.0 END  ELSE 1.0  END) +  (CASE type WHEN ''9.3'' THEN 40.0  ELSE 0.0  END)  )  END )::float8 AS reverse_cost, ' || 'x1, y1, x2, y2 FROM edges', " + str(destination_route) + ", " + str(origin_route) + ", TRUE, TRUE)) as t1, edges as t2 where t1.id2 = t2.edge_id

door = ''S'' means door is closed, and in this case, value is -1.

Answer 1

I assume you can check your connection status in python (I don't use python) so you can recover and do something sensible, like reconnect. You might need to sleep for a couple of seconds to let the database recover from the crash before you reconnect.

Regarding the pgrouting issue, I would like to see a simple test case that can reproduce this problem in pgadmin or psql shell, filed as a bug so I can look into it. Our code should never crash the server, but sometimes it does and we need to fix those issues.