use*_*372 2 c++ postgresql error-handling libpq
我正在创建一些简单的帮助器类和使用libpq的方法,我想知道我是否从数据库收到错误 - (例如SQL错误),我应该如何处理它？
目前,每个方法都会返回一个bool,具体取决于操作是否成功,因此在继续执行新操作之前由用户进行检查.
但是,在阅读libpq文档后,如果发生错误,我能想到的最好的是我应该记录错误消息/状态,否则忽略.例如,如果应用程序处于事务中间,那么我相信它仍然可以继续(据我所知,Postgresql不会取消事务).
我可以用PostgreSQL/libpq做些什么来使这些错误的后果对数据库服务器安全,或者是无知更好的策略？
您应该检查SQLSTATE错误,并根据该处理决定,仅此.切勿尝试根据错误消息文本在代码中做出决策.
应用程序应该只针对某些类型的错误重试事务:
对于连接错误,您应该重新连接然后重新尝试该事务.
当然,您希望设置重试次数的限制,因此如果问题没有解决,则不会永远循环.
其他类型的错误不会通过再次尝试来解决,因此应用程序应该向客户端报告错误.语法错误？独特违规？检查约束违规？再次运行该语句无济于事.
文档中有一个错误代码列表,但文档没有解释每个错误,但序言部分非常有用.
在旁注:避免陷入的一个陷阱是在使用它们之前使用普通查询"测试"连接,并假设这意味着真正的查询不会失败.那是一场竞争.不要打扰测试连接; 只需运行真实的查询并处理任何错误.
究竟要做什么的细节取决于错误和应用程序.如果有一个总是正确的答案,libpq已经为你做了.
我的建议:
在您必须重新运行之前,始终保留事务记录,直到您从数据库获得确认的提交.不要只是发送并忘记SQL语句.
在没有断开连接的情况下重试事务并重新连接SQLSTATE 40001(serialization_failure)和40P01(deadlock_detected),因为这些是通常通过重新尝试解决的瞬态条件.您应该记录它们,因为它们有机会改善应用程序与数据库的交互方式,如果它们发生了很多,那么它们就是性能问题.
对于错误类08(连接异常),至少断开,重新连接并重试该事务一次.
处理53300(too_many_connections)和53400(超出连接限制)具有特定且信息性错误的用户.与其他53类条目相同.
处理57具有特定和信息性错误的类的条目给用户.如果你得到query_cancelled(57014),不要重试,这会让系统管理员非常生气.
25006通过报告不同的错误来处理(read_only_sql_transaction),告诉用户您尝试写入只读数据库或使用只读事务.
为23505(UNIQUE违规)报告不同的错误,表明唯一约束或主键约束中存在冲突.重试是没有意义的.
错误类01不应该产生异常.
将其他情况视为错误并将其报告给调用者,并提供问题的详细信息 - 最重要的是SQLSTATE.如果返回简化错误,请记录所有详细信息.
希望这很有用.
| 归档时间： |
|
| 查看次数： |
1156 次 |
| 最近记录： |