{"Entry":{"collection":"protocol","key":"backendkeydata-b","name":"BackendKeyData","aliases":["BackendKeyData","Byte1('K')"],"metadata":{"aliases":["BackendKeyData","Byte1('K')"],"category":"Backend messages","content_hash":"2998315d462c1ed1fee8f9ddbe97fe6f8adf239de9d3ad3d0b1b97bd18e3e5de","derived_content_hash":"41533e71d7ff4a15058a80acd1d004ec0e4259876734106a031928ff091811f7","imported_at":"2026-09-30T00:40:44.434115+08:00","name":"BackendKeyData","name_zh":"","slug":"backendkeydata-b","summary":"BackendKeyData is a backend protocol message. Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later."}},"Definition":{"Collection":"protocol","Key":"backendkeydata-b","SourceDatabase":"center","Version":"18","SourceTable":"protocol_message","SourceKey":"backendkeydata-b","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"direction":"B","fields":[{"description":"Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.","format":"Byte1('K')"},{"description":"Length of message contents in bytes, including self.","format":"Int32"},{"description":"The process ID 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"}]},"comparison_hash":"849b59845ce57aff411d6d20d1a8dcfe78053ff3861c87a5d4d026cea7dfa067","description":["BackendKeyData is a backend protocol message. Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later."],"description_zh":"Byte1('K') 将此消息标识为取消请求密钥数据。如果前端希望以后能够发送 CancelRequest 消息，就必须保存这些值。 Int32 消息内容的长度（以字节为单位），包括其自身。 Int32 此后端的进程 ID。 Byte n 此后端的密钥。此字段延伸至消息末尾，其范围由长度字段确定。 密钥长度最小为 4 字节，最大为 256 字节。 PostgreSQL 服务器只发送最长 32 字节的密钥，但更大的长度上限允许未来的服务器版本、连接池和其他中间件使用更长的密钥。一种可能的用途是在服务器密钥中附加额外信息。因此，也建议中间件不要用尽所有字节，以便多层中间件叠加时，每一层都可以在密钥外再附加数据。 在协议版本 3.2 之前，密钥始终为 4 字节长。","description_zh_html":"\u003cp\u003e协议消息 BackendKeyData (B)。\u003c/p\u003e\u003ch3\u003e同版本中文手册定义\u003c/h3\u003e\u003cdd\u003e\u003cdiv class=\"variablelist\"\u003e\u003cdl class=\"variablelist\"\u003e\u003cdt\u003e\u003cspan class=\"term\"\u003eByte1('K')\u003c/span\u003e \u003c/dt\u003e\u003cdd\u003e\u003cp\u003e\n         将此消息标识为取消请求密钥数据。如果前端希望以后能够发送 CancelRequest 消息，就必须保存这些值。\n        \u003c/p\u003e\u003c/dd\u003e\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e \u003c/dt\u003e\u003cdd\u003e\u003cp\u003e\n         消息内容的长度（以字节为单位），包括其自身。\n        \u003c/p\u003e\u003c/dd\u003e\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e \u003c/dt\u003e\u003cdd\u003e\u003cp\u003e\n         此后端的进程 ID。\n        \u003c/p\u003e\u003c/dd\u003e\u003cdt\u003e\u003cspan class=\"term\"\u003eByte\u003cem class=\"replaceable\"\u003e\u003ccode\u003en\u003c/code\u003e\u003c/em\u003e\u003c/span\u003e \u003c/dt\u003e\u003cdd\u003e\u003cp\u003e\n         此后端的密钥。此字段延伸至消息末尾，其范围由长度字段确定。\n        \u003c/p\u003e\u003cp\u003e\n         密钥长度最小为 4 字节，最大为 256 字节。\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 服务器只发送最长 32 字节的密钥，但更大的长度上限允许未来的服务器版本、连接池和其他中间件使用更长的密钥。一种可能的用途是在服务器密钥中附加额外信息。因此，也建议中间件不要用尽所有字节，以便多层中间件叠加时，每一层都可以在密钥外再附加数据。\n        \u003c/p\u003e\u003c/dd\u003e\u003c/dl\u003e\u003c/div\u003e\u003cp\u003e\n      在协议版本 3.2 之前，密钥始终为 4 字节长。\n     \u003c/p\u003e\u003c/dd\u003e\u003cp\u003e\u003ca href=\"/zh/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA\"\u003e查看完整中文手册与上下文\u003c/a\u003e。\u003c/p\u003e","direction":"B","facts":[{"label":"Direction","value":"Backend → frontend"},{"label":"First wire field","value":"Byte1('K')"},{"label":"Field entries","value":"4"},{"label":"Documented flow contexts","value":"Start-up"}],"facts_zh":[{"label":"方向","value":"后端 → 前端"},{"label":"首个线上协议字段","value":"Byte1('K')"},{"label":"字段条目","value":"4"},{"label":"手册中的交互阶段","value":"启动"}],"fields":[{"description":"Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.","format":"Byte1('K')"},{"description":"Length of message contents in bytes, including self.","format":"Int32"},{"description":"The process ID 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"}],"manual_html":"\u003cdl\u003e\u003cdd\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eByte1('K')\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIdentifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eLength of message contents in bytes, including self.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe process ID of this backend.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eByte\u003cem class=\"replaceable\"\u003e\u003ccode\u003en\u003c/code\u003e\u003c/em\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe secret key of this backend. This field extends to the end of the message, indicated by the length field.\u003c/p\u003e\n\u003cp\u003eThe minimum and maximum key length are 4 and 256 bytes, respectively. The \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 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.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eBefore protocol version 3.2, the secret key was always 4 bytes long.\u003c/p\u003e\n\u003c/dd\u003e\u003c/dl\u003e","manual_path":"/docs/18/protocol-message-formats.html","related":[{"label":"Protocol flow and exchange examples","url":"/docs/18/protocol-flow.html"},{"label":"Protocol overview","url":"/docs/18/protocol-overview.html"},{"label":"Start-up","url":"/docs/18/protocol-flow.html#PROTOCOL-FLOW-START-UP"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[{"paragraphs":["The complete definition below retains repetition, counts and conditional fields. A numbered table row is a documented field definition, not a fixed byte offset. Integer encodings and flow rules follow the same-version protocol chapter."],"title":"Framing and repetition"}],"sections_zh":[{"paragraphs":["下方完整定义保留重复项、计数与条件字段。表格行号表示文档中的字段定义，并非固定字节偏移量。整数编码与交互流程以同版本协议章节为准。"],"title":"消息边界与重复字段"}],"signature":"BackendKeyData (B)","sources":[{"label":"PostgreSQL 18 English manual","path":"protocol-message-formats.html","sha256":"53f37652ac2c089e30ada87d8aee7bdd0f26695b03f275302e526a807d2a1f23","url":"/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA"}],"tables":[{"columns":[{"key":"c0","label":"Position"},{"key":"c1","label":"Format"},{"key":"c2","label":"Meaning"}],"key":"fields","rows":[{"c0":"1","c1":"Byte1('K')","c2":"Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later."},{"c0":"2","c1":"Int32","c2":"Length of message contents in bytes, including self."},{"c0":"3","c1":"Int32","c2":"The process ID of this backend."},{"c0":"4","c1":"Byte n","c2":"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."}],"title":"Wire fields in documented order"}],"tables_zh":[{"columns":[{"key":"c0","label":"位置"},{"key":"c1","label":"格式"},{"key":"c2","label":"含义"}],"key":"fields","rows":[{"c0":"1","c1":"Byte1('K')","c2":"将此消息标识为取消请求密钥数据。如果前端希望以后能够发送 CancelRequest 消息，就必须保存这些值。"},{"c0":"2","c1":"Int32","c2":"消息内容的长度（以字节为单位），包括其自身。"},{"c0":"3","c1":"Int32","c2":"此后端的进程 ID。"},{"c0":"4","c1":"Byte n","c2":"此后端的密钥。此字段延伸至由长度字段指示的消息末尾，密钥长度最小为 4 字节、最大为 256 字节。PostgreSQL 服务器发送的密钥目前最多为 32 字节；更大的上限允许未来的服务器版本、连接池和其他中间件使用更长的密钥，例如在服务器密钥中附加额外信息。因此也建议中间件不要用尽全部字节，以便多个叠加的中间件都能向密钥附加数据。"}],"title":"按手册顺序排列的线上协议字段"}],"zh_from":{"authored_translation":"source-derived-identity","body_sha256":"7f498c2b556fbca8114196a03d68fac573a5d528abbfd632f8cb4c9048b3397b","kind":"same-version-chinese-manual-with-source-derived-identity","manual":{"anchor":"PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA","build_id":107,"extraction":"exact-definition","fragment_sha256":"1fc59483c47f7bbfd0c1762015fa762db04b03f97be18838cf1d977869a409fb","locale":"zh-Hans","page_key":"protocol-message-formats.html","source_hash":"0be0a37b38d80c96c157ca9fcfe9222995654664aad8136f7ac2b1b552f6753a","source_revision":"unknown:rendered-translation-baseline","translated_from_revision":null,"translation_revision":"git:b1b500221dbe5437cfca004d6b04d3f6e422765d;html-sha256:08e987a66af27b98444a8057c256314eafa13611a3fb9e888214fc436824244b","url":"/zh/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA","version":"18"},"runtime_rerun":false,"source_facts_revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}},"ManualEvidence":{"manual_path":"/docs/18/protocol-message-formats.html","release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"PostgreSQL 18 English manual","path":"protocol-message-formats.html","sha256":"53f37652ac2c089e30ada87d8aee7bdd0f26695b03f275302e526a807d2a1f23","url":"/docs/18/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-BACKENDKEYDATA"}]},"MeasuredEvidence":{}},"Text":{"Collection":"protocol","Key":"backendkeydata-b","SourceDatabase":"center","Version":"18","Locale":"en","Title":"BackendKeyData","Summary":"BackendKeyData is a backend protocol message. Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.","BodyHTML":"\u003cdl\u003e\u003cdd\u003e\n\u003cdiv\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cspan\u003eByte1(\u0026#39;K\u0026#39;)\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIdentifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eLength of message contents in bytes, including self.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe process ID of this backend.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003eByte\u003cem\u003e\u003ccode\u003en\u003c/code\u003e\u003c/em\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe secret key of this backend. This field extends to the end of the message, indicated by the length field.\u003c/p\u003e\n\u003cp\u003eThe minimum and maximum key length are 4 and 256 bytes, respectively. The \u003cspan\u003ePostgreSQL\u003c/span\u003e 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\u0026#39;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.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eBefore protocol version 3.2, the secret key was always 4 bytes long.\u003c/p\u003e\n\u003c/dd\u003e\u003c/dl\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"f257df04ec09bd0c60b9b73d0db2e3830dc3cafb35179915ff750859fec4279a","Payload":{"description":["BackendKeyData is a backend protocol message. Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later."],"manual_html":"\u003cdl\u003e\u003cdd\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eByte1('K')\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIdentifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eLength of message contents in bytes, including self.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eInt32\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe process ID of this backend.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eByte\u003cem class=\"replaceable\"\u003e\u003ccode\u003en\u003c/code\u003e\u003c/em\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eThe secret key of this backend. This field extends to the end of the message, indicated by the length field.\u003c/p\u003e\n\u003cp\u003eThe minimum and maximum key length are 4 and 256 bytes, respectively. The \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 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.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eBefore protocol version 3.2, the secret key was always 4 bytes long.\u003c/p\u003e\n\u003c/dd\u003e\u003c/dl\u003e","related":[{"label":"Protocol flow and exchange examples","url":"/docs/18/protocol-flow.html"},{"label":"Protocol overview","url":"/docs/18/protocol-overview.html"},{"label":"Start-up","url":"/docs/18/protocol-flow.html#PROTOCOL-FLOW-START-UP"}],"sections":[{"paragraphs":["The complete definition below retains repetition, counts and conditional fields. A numbered table row is a documented field definition, not a fixed byte offset. Integer encodings and flow rules follow the same-version protocol chapter."],"title":"Framing and repetition"}],"tables":[{"columns":[{"key":"c0","label":"Position"},{"key":"c1","label":"Format"},{"key":"c2","label":"Meaning"}],"key":"fields","rows":[{"c0":"1","c1":"Byte1('K')","c2":"Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later."},{"c0":"2","c1":"Int32","c2":"Length of message contents in bytes, including self."},{"c0":"3","c1":"Int32","c2":"The process ID of this backend."},{"c0":"4","c1":"Byte n","c2":"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."}],"title":"Wire fields in documented order"}]}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}