BackendKeyData
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.
Reading PG 18·Select a recorded version
- Direction
- Backend → frontend
- First wire field
- Byte1('K')
- Field entries
- 4
- Documented flow contexts
- Start-up
- direction
- B
- manual path
- /docs/18/protocol-message-formats.html
- signature
- BackendKeyData (B)
Definition PG 18
-
- Byte1('K')
-
Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later.
- Int32
-
Length of message contents in bytes, including self.
- Int32
-
The process ID of this backend.
- Byte
n -
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.
Before protocol version 3.2, the secret key was always 4 bytes long.
Wire fields in documented order
| Position | Format | Meaning |
|---|---|---|
| 1 | Byte1('K') | Identifies the message as cancellation key data. The frontend must save these values if it wishes to be able to issue CancelRequest messages later. |
| 2 | Int32 | Length of message contents in bytes, including self. |
| 3 | Int32 | The process ID of this backend. |
| 4 | Byte n | 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. |
Compare versions
Complete source facts
fields
map[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')], map[description:Length of message contents in bytes, including self. format:Int32], map[description:The process ID of this backend. format:Int32], map[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]Source references
Full definition and evidence JSON
Definition sources
center · PostgreSQL 18 · 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f
Text language: en · 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f