【问题标题】:pgRouting stopped working after database backuppgRouting 在数据库备份后停止工作
【发布时间】:2014-12-14 10:07:46
【问题描述】:

我在 postgresql PATHWAY 中有这两个表,以及我使用 pgr_createTopology 创建的顶点表,称为 PATHWAY_VERTICES_PGR。一切都很好,直到我决定备份数据库以便以后恢复它,现在我已经恢复了它,使用相同的 postgres 9.3.4 x64、postgis 2.1.3 和 pgrouting 2.0 版本,没有任何改变,但事实是我已经恢复它,现在 pgr_dijkstra 停止工作,每次我查询 pgr_dijkstra 时都会收到此错误:

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 错误代码很难破译

【问题讨论】:

  • 消息:“错误:计算路径错误:捕获到未知异常!”意味着 C++ 代码中的某些东西爆炸了。这和以前的硬件一样吗?更多或更少的内存? postgresql.conf 文件是否已更改?任何 pgr_dijkstra() 查询都有效吗?你有巨大的节点 ID,这可能是个问题,因为它需要大量的内存。您可以尝试重新编号节点,看看是否可行。
  • 与以前相同的硬件,相同的操作系统,32GB 或内存,我还备份了整个数据文件夹以防万一,所以所有 conf 文件都完全相同,最短路径查询我把其他过滤器放到减少内存使用。我将制作几个新的表(edges + vertices_pgr),包含 100k 条记录,以测试这是否是内存问题。还使用另一种可用的最短路径方法 bdDijkstra 和 A* 进行测试
  • 请参阅gis.stackexchange.com/questions/112739/… 了解有关此问题的详细技术答案...

标签: sql postgresql postgis pgrouting


【解决方案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 行,尝试分配大量内存:

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间接相关

【讨论】:

  • 我不知道这个特定的问题是否在 pgsql 9.4 中得到解决,但是在将服务器和数据库文件升级到新版本后,问题消失了,现在像黄油一样查询,没有任何分配问题。感谢您的输入,它为我节省了很多时间:)
猜你喜欢
  • 1970-01-01
  • 2021-05-26
  • 2015-06-04
  • 1970-01-01
  • 2018-12-25
  • 2018-09-05
  • 1970-01-01
  • 2012-08-09
  • 1970-01-01
相关资源
最近更新 更多