Question

我试图通过将其part_number列进一步解析为属性来扩展项目配置文件表。它在函数外工作正常。

ALTER TABLE tbl_item_info
    ADD prop1 varchar(2),
    ADD prop2 varchar(1),
    ADD prop3 numeric(4,3);

UPDATE tbl_item_info
    SET prop1 = substr(part_num,5,2)
    ,   prop2 = substr(part_num,7,1) 
    ,   prop3 = to_number( substr(part_num,8,5) , '9G999')
    WHERE ARRAY[left(part_num,3)] <@ ARRAY['NTX','EXC'] ;

但是当我尝试将语句放入函数中时。它始终失败，错误＆＃34;与OID xxxxx的关系不存在＆＃34;指向UPDATE语句。

我不知道它想说什么。知道为什么吗？

Answer 1

我希望我有一个明确的答案，但这似乎与PostgreSQL中的已知错误有关，如下所述：

https://github.com/greenplum-db/gpdb/issues/1094

请记住，PostgreSQL的greenplum实现是Dell EMC专有的，但是，核心代码问题可能与所有主要的PostgreSQL发行版相同。我仍在研究这个问题，以确定是否有一个很好的解决方案。我遇到明显类似错误的数据库不是PostgreSQL的greenplum实现。当我在一个oid上的查询中调用pg_relation_filepath（）函数时，抛出了错误，该函数是从pg_class表中的记录中动态获得的，该记录应该在./base/路径的子目录中有一个关联的外部文件。引发的错误是：

错误：关系“pg_toast_34474_index”不存在

这里的要点是，对于存在的toast实体，它应该被绑定到另一个关系，并作为对在存储介质上创建的其他文件的引用，以容纳不适合拥有关系的其他数据。顶级文件 - 在这种情况下，很可能是一个表。但是当我搜索拥有关系的oid（34474）时，所有者不存在。由于所有者不存在，我认为逻辑假定toast实体也没有，即使它在pg_class表中有记录。

这就像我现在可以找到根本原因一样接近。虽然上面的链接建议改进问题的代码应该已经在8.3版本中发布，但是我的数据库已经从版本8.1升级到版本9.4.7，所以看起来即使代码可能在这两个版本之间有所改进以防止问题的新发生，如果问题是在数据库升级之前创建的，那么较新的代码不知道如何在实现修复之前重新组装由此明显错误创建的问题留下的修补玩具。

目前我正在调查PLPGSQL函数是否可以包装并捕获所有关系的错误，以便我可以确定哪些问题（以及解决我确定哪个关系托管在特定文件中的原始问题server.postmaster日志告诉我它无法读取 - 希望它只是一个我可以删除/创建的索引。

Postgresql函数失败，＆＃34;与OID xxxxx的关系不存在＆＃34;

1 个答案: