2014-10-19 67 views
0

工作後我在PostgreSQL裏,途徑這兩個桌子,和我使用pgr_createTopology,稱爲PATHWAY_VERTICES_PGR創建頂點表。一切都很好,直到我決定備份數據庫以在以後恢復它時,現在我已經恢復了它,使用相同的postgres 9.3.4 x64,postgis 2.1.3和pgrouting 2.0版本,沒有任何改變,但事實上我已經恢復它,現在pgr_dijkstra停止工作,即時我每次查詢pgr_dijkstra時間收到此錯誤:pgRouting停止數據庫備份

ERRO: Error computing path: Unknown exception caught! 
********** Error ********** 
ERRO: Error computing path: Unknown exception caught! 
SQL state: 38001 

但是當我搜索錯誤代碼:

38001 containing_sql_not_permitted 

,這是完全查詢的例子罰款直到恢復:

SELECT seq, id1 AS node, id2 AS edge, cost, geom FROM pgr_dijkstra(' SELECT r.gid as id, r.source, r.target, st_length(r.geom) as cost,r.geom FROM PATHWAY r' ,956358,734134, false, false) as di JOIN PATHWAY pt ON di.id2 = pt.gid 

我已經嘗試重新安裝Postgres,刪除並重新添加postgis和pgrouting擴展,但錯誤仍然存​​在。如果你們有任何想法,讓我知道,這些PostgreSQL的錯誤代碼是難以破譯

+0

消息:「ERRO:錯誤計算路徑:未知異常捕獲」意味着C++代碼中的某些東西爆發了。這是和以前一樣的硬件嗎?或多或少的記憶?有postgresql.conf文件更改?是否有任何pgr_dijkstra()查詢工作?你有巨大的節點ID,這可能是一個問題,因爲它需要大量的內存。你可以嘗試重新編號你的節點,看看是否有效。 – 2014-10-19 16:07:48

+0

與以前相同的硬件,相同的操作系統,32GB或RAM,我也有整個數據文件夾備份,以防萬一所有conf文件都完全相同,最短路徑查詢我放其他過濾器,以減少內存使用情況。 我將用100k記錄製作一對新的表格(邊緣+ vertices_pgr),以測試這是否是內存問題。 可用,bdDijkstra和A另一最短路徑的方法也測試* – catacavaco 2014-10-20 03:00:00

+0

請參閱http://gis.stackexchange.com/questions/112739/pgrouting-pgr-dijkstra-function-error 進行了詳細的技術解答上這... – ricquochet 2014-12-09 14:49:54

回答

1

這是一個內存分配問題。

你的源和目標節點具有較高的id和PgRouting嘗試分配基於最高節點ID,它可以找到的內存,即使只在圖中的一些邊緣和節點。

Dijkstra算法,drivingDistance等功能有同樣的問題。 恕我直言,這是一個真正的問題,因爲你不能從巨大的圖中選擇一個子圖,而不重新編號邊和節點,這使得這些功能的查詢參數不可用。

一個簡單的測試用例來重現問題:創建一個帶有1個邊的小圖,起始和結束節點id爲2 000 000 000和2 000 000 001.您將在這兩個節點上得到運行dijkstra的錯誤。

技術分析如下:

綜觀C源代碼(PgRouting V2.0.0),在SRC \ bd_dijkstra \ SRC:

bdsp.c 

... 線271:計算最大的節點id

for(z=0; z<total_tuples; z++) { 
    if(edges[z].source<v_min_id) v_min_id=edges[z].source; 
    if(edges[z].source>v_max_id) v_max_id=edges[z].source; 
    if(edges[z].target<v_min_id) v_min_id=edges[z].target; 
    if(edges[z].target>v_max_id) v_max_id=edges[z].target; 

然後線315,v_max_id被用作參數...

ret = bidirsp_wrapper(edges, total_271tuples, v_max_id + 2, start_vertex, end_vertex, 
         directed, has_reverse_cost, 
         path, path_count, &err_msg); 
在BiDirDijkstra.cpp

... 線281,v_max_id + 2 = maxNode

int BiDirDijkstra::bidir_dijkstra(edge_t *edges, unsigned int edge_count, int maxNode, int start_vertex, int end_vertex, 
       path_element_t **path, int *path_count, char **err_msg) 
{ 
    max_node_id = maxNode; 
    max_edge_id = -1; 

    // Allocate memory for local storage like cost and parent holder 
    DBG("calling initall(maxNode=%d)\n", maxNode); 
    initall(maxNode); 

,然後管線67,試圖分配的存儲器中的LOT:

void BiDirDijkstra::initall(int maxNode) 
{ 
    int i; 
    m_vecPath.clear(); 
    DBG("BiDirDijkstra::initall: allocating m_pFParent, m_pRParent maxNode: %d\n", maxNode+1); 
    m_pFParent = new PARENT_PATH[maxNode + 1]; 
    m_pRParent = new PARENT_PATH[maxNode + 1]; 
    DBG("BiDirDijkstra::initall: allocated m_pFParent, m_pRParent\n"); 

    DBG("BiDirDijkstra::initall: allocating m_pFCost, m_pRCost maxNode: %d\n", maxNode+1); 
    m_pFCost = new double[maxNode + 1]; 
    m_pRCost = new double[maxNode + 1]; 
... 

間接相關到http://pgrouting.974090.n3.nabble.com/pgrouting-dev-PGR-2-Add-some-robustness-to-the-boost-wrappers-td4025087.html

+0

我不知道這個特定問題是否已在pgsql 9.4中解決,但是在將服務器和數據庫文件升級到新版本後,問題消失了,現在像黃油一樣查詢,沒有任何分配問題。 謝謝你的輸入,它爲我節省了很多時間:) – catacavaco 2015-02-15 00:04:47