{"Entry":{"collection":"protocol","key":"backendkeydata-b","name":"BackendKeyData","aliases":["BackendKeyData","Byte1('K')"],"metadata":{"aliases":["BackendKeyData","Byte1('K')"],"category":"Backend messages","content_hash":"2998315d462c1ed1fee8f9ddbe97fe6f8adf239de9d3ad3d0b1b97bd18e3e5de","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."],"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"}],"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"}],"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"}]},"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":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}