BackendKeyData

BackendKeyData 是后端协议消息，表示用于取消请求的密钥数据。前端如需在之后发送 CancelRequest 消息，必须保存这些值。

当前查看 PostgreSQL 18.6。

说明

BackendKeyData 是后端协议消息，表示用于取消请求的密钥数据。前端如需在之后发送 CancelRequest 消息，必须保存这些值。

方向: 后端 → 前端
首个线上协议字段: Byte1('K')
字段条目: 4
手册中的交互阶段: 启动

用法

BackendKeyData (B)

消息边界与重复字段

下方完整定义保留重复项、计数与条件字段。表格行号表示文档中的字段定义，并非固定字节偏移量。整数编码与交互流程以同版本协议章节为准。

按手册顺序排列的线上协议字段

位置	格式	含义
1	Byte1('K')	将此消息标识为取消请求密钥数据。如果前端希望以后能够发送 CancelRequest 消息，就必须保存这些值。
2	Int32	消息内容的长度（以字节为单位），包括其自身。
3	Int32	此后端的进程 ID。
4	Byte n	此后端的密钥。此字段延伸至由长度字段指示的消息末尾，密钥长度最小为 4 字节、最大为 256 字节。PostgreSQL 服务器发送的密钥目前最多为 32 字节；更大的上限允许未来的服务器版本、连接池和其他中间件使用更长的密钥，例如在服务器密钥中附加额外信息。因此也建议中间件不要用尽全部字节，以便多个叠加的中间件都能向密钥附加数据。

手册定义

Byte1('K')

将此消息标识为取消请求密钥数据。如果前端希望以后能够发送 CancelRequest 消息，就必须保存这些值。

Int32

消息内容的长度（以字节为单位），包括其自身。

Int32

此后端的进程 ID。

Byte n

此后端的密钥。此字段延伸至消息末尾，其范围由长度字段确定。

密钥长度最小为 4 字节，最大为 256 字节。PostgreSQL 服务器只发送最长 32 字节的密钥，但更大的长度上限允许未来的服务器版本、连接池和其他中间件使用更长的密钥。一种可能的用途是在服务器密钥中附加额外信息。因此，也建议中间件不要用尽所有字节，以便多层中间件叠加时，每一层都可以在密钥外再附加数据。

在协议版本 3.2 之前，密钥始终为 4 字节长。

文档与源码

PostgreSQL 18 English manual

来源构建

版本: 18.6
构建: https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2
来源指纹: 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

版本比较

PostgreSQL 17 → 18: 属性变化。

以下差异保留原始字段名与英文源描述。

--- PostgreSQL 17
+++ PostgreSQL 18
@@ -7,15 +7,15 @@
     },
     {
       "description": "Length of message contents in bytes, including self.",
-      "format": "Int32(12)"
+      "format": "Int32"
     },
     {
       "description": "The process ID of this backend.",
       "format": "Int32"
     },
     {
-      "description": "The secret key of this backend.",
-      "format": "Int32"
+      "description": "The secret key of this backend. This field extends to the end of the message, indicated by the length field. The minimum and maximum key length are 4 and 256 bytes, respectively. The PostgreSQL server only sends keys up to 32 bytes, but the larger maximum size allows for future server versions, as well as connection poolers and other middleware, to use longer keys. One possible use case is augmenting the server's key with extra information. Middleware is therefore also encouraged to not use up all of the bytes, in case multiple middleware applications are layered on top of each other, each of which may wrap the key with extra data.",
+      "format": "Byte n"
     }
   ]
 }

比较已记录的接口与属性，排除来源指纹和构建元数据。某个样本中没有记录，不能据此判断实际引入或移除的版本。

快速链接