当前位置: 首页 > Database, postgresql > 正文

postgresql 异步消息处理

有几种情况下后端会发送一些并非由特定的前端的命令流提示的消息。 在任何时候前端都必须准备处理这些信息,即使是并未涉及到查询的处理的时候。 至少,我们应该在开始读取查询响应之前检查这些情况。

NoticeResponse 消息有可能是因为外部的活动而生成的; 比如,如果数据库管理员进行一次”快速”数据库关闭, 那么后端将在关闭连接之前发送一个 NoticeResponse 来表明这些。 因此,前端应该总是准备接受和显示 NoticeResponse 消息,即使连接通常是空闲的时候也如此。

如果后端认为前端应该知道的任何参数的活跃数值发生了变化, 那么都会产生 ParameterStatus 消息。这些最常见发生的地方是前端执行的一个 SET SQL 命令的响应, 并且这个时候实际上是同步 — 但是也有可能是数据库管理员改变了配置文件然后 SIGHUP 了 postmaster 导致的参数状态的变化。 同样,如果一个 SET 命令回滚,那么也会生成合适的 ParameterStatus 消息以报告当前有效的数值。

目前,系统内有一套会生成 ParameterStatus 消息的写成硬代码的参数: 他们是 server_version, server_encoding, client_encoding, is_superuser, session_authorization, DateStyle, TimeZone, integer_datetimes 和 standard_conforming_strings。 (server_encoding,TimeZone 和 integer_datetimes 在 8.0 版本之前没有报告。standard_conforming_strings 在版本 8.1 之前没有报告。) 请注意 server_version, server_encoding 和 integer_datetimes 是伪参数,启动后不能修改。 这些可能在将来改变,或者甚至是变成可以配置的。 因此,前端应该简单地忽略那些它不懂或者不关心的 ParameterStatus。

如果前端发出一个 LISTEN 命令, 那么后端将在为同一个通知名执行了 NOTIFY 命令后发送一个 NotificationResponse 消息(不要和 NoticeResponse 混了!)。

注意: 目前,NotificationResponse 只能在一个事务外面发送,因此它将不会在一个命令响应序列中间出现, 但是它可能在 ReadyForQuery 之前出现。不过,在前端逻辑中做上述假设是不明智的。好的做法是在协议的任何点上都可以接受 NotificationResponse。

    分享到:

本文固定链接: http://klwang.info/postgresql-asynchronism-message/ | 数据库|Linux|软件开发

该日志由 klwang 于2014年01月27日发表在 Database, postgresql 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: postgresql 异步消息处理 | 数据库|Linux|软件开发
关键字: ,

postgresql 异步消息处理:等您坐沙发呢!

发表评论

*
快捷键:Ctrl+Enter