|
19 | 19 |
|
20 | 20 | <para>
|
21 | 21 | This document describes version 3.2 of the protocol, introduced in
|
22 |
| - <productname>PostgreSQL</productname> version 17. The server is compatible with |
23 |
| - protocol version 3.0, implemented in |
24 |
| - <productname>PostgreSQL</productname> 7.4 and later. For descriptions |
25 |
| - of earlier protocol versions, see previous releases of the |
26 |
| - <productname>PostgreSQL</productname> documentation. |
27 |
| - </para> |
28 |
| - |
29 |
| - <para> |
30 |
| - A single server |
31 |
| - can support multiple protocol versions. The initial startup-request |
32 |
| - message tells the server which protocol version the client is attempting to |
33 |
| - use. If the major version requested by the client is not supported by |
34 |
| - the server, the connection will be rejected (for example, this would occur |
35 |
| - if the client requested protocol version 4.0, which does not exist as of |
36 |
| - this writing). If the minor version requested by the client is not |
37 |
| - supported by the server (e.g., the client requests version 3.2, but the |
38 |
| - server supports only 3.0), the server may either reject the connection or |
39 |
| - may respond with a NegotiateProtocolVersion message containing the highest |
40 |
| - minor protocol version which it supports. The client may then choose either |
41 |
| - to continue with the connection using the specified protocol version or |
42 |
| - to abort the connection. |
43 |
| - </para> |
44 |
| - |
45 |
| - <para> |
46 |
| - The protocol negotiation was introduced in |
47 |
| - <productname>PostgreSQL</productname> version 9.3.21. Earlier versions would |
48 |
| - reject the connection if the client requested a minor version that was not |
49 |
| - supported by the server. |
50 |
| - </para> |
51 |
| - |
52 |
| - <para> |
53 |
| - The difference between protocol version 3.0 and 3.2 is that the secret key |
54 |
| - used in query cancellation was enlarged from 4 bytes to a variable length |
55 |
| - field. The BackendKeyData message was changed to accomodate that, and the |
56 |
| - CancelRequest message was redefined to have a variable length payload. |
| 22 | + <productname>PostgreSQL</productname> version 17. The server and the libpq |
| 23 | + client library is compatible with protocol version 3.0, implemented in |
| 24 | + <productname>PostgreSQL</productname> 7.4 and later. |
57 | 25 | </para>
|
58 | 26 |
|
59 | 27 | <para>
|
|
219 | 187 | server versions; the text format is usually the more portable choice.
|
220 | 188 | </para>
|
221 | 189 | </sect2>
|
| 190 | + |
| 191 | + <sect2 id="protocol-versions"> |
| 192 | + <title>Protocol versions</title> |
| 193 | + |
| 194 | + <para> |
| 195 | + The current, latest version of the protocol is version 3.2. For backwards |
| 196 | + compatibility with old server versions and middleware that don't support |
| 197 | + the version negotiation yet, the libpq library still uses protocol version |
| 198 | + 3.0 by default however. |
| 199 | + </para> |
| 200 | + |
| 201 | + <para> |
| 202 | + A single server can support multiple protocol versions. The initial |
| 203 | + startup-request message tells the server which protocol version the client |
| 204 | + is attempting to use. If the major version requested by the client is not |
| 205 | + supported by the server, the connection will be rejected (for example, |
| 206 | + this would occur if the client requested protocol version 4.0, which does |
| 207 | + not exist as of this writing). If the minor version requested by the |
| 208 | + client is not supported by the server (e.g., the client requests version |
| 209 | + 3.2, but the server supports only 3.0), the server may either reject the |
| 210 | + connection or may respond with a NegotiateProtocolVersion message |
| 211 | + containing the highest minor protocol version which it supports. The |
| 212 | + client may then choose either to continue with the connection using the |
| 213 | + specified protocol version or to abort the connection. |
| 214 | + </para> |
| 215 | + |
| 216 | + <para> |
| 217 | + The protocol negotiation was introduced in |
| 218 | + <productname>PostgreSQL</productname> version 9.3.21. Earlier versions |
| 219 | + would reject the connection if the client requested a minor version that |
| 220 | + was not supported by the server. |
| 221 | + </para> |
| 222 | + |
| 223 | + <table> |
| 224 | + <title>Protocol versions</title> |
| 225 | + |
| 226 | + <tgroup cols="2"> |
| 227 | + <thead> |
| 228 | + <row> |
| 229 | + <entry>Version</entry> |
| 230 | + <entry>Supported by</entry> |
| 231 | + <entry>Description</entry> |
| 232 | + </row> |
| 233 | + </thead> |
| 234 | + |
| 235 | + <tbody> |
| 236 | + <row> |
| 237 | + <entry>3.2</entry> |
| 238 | + <entry>PostgreSQL 18 and later</entry> |
| 239 | + <entry>Current latest version. The secret key used in query |
| 240 | + cancellation was enlarged from 4 bytes to a variable length field. The |
| 241 | + BackendKeyData message was changed to accomodate that, and the CancelRequest |
| 242 | + message was redefined to have a variable length payload. |
| 243 | + </entry> |
| 244 | + </row> |
| 245 | + <row> |
| 246 | + <entry>3.1</entry> |
| 247 | + <entry>-</entry> |
| 248 | + <entry>Reserved. Version 3.1 has not been used by any PostgreSQL |
| 249 | + version, but it was skipped because old versions of the popular |
| 250 | + pgbouncer application had a bug in the protocol negotiation which made |
| 251 | + it incorrectly claim that it supported version 3.1. |
| 252 | + </entry> |
| 253 | + </row> |
| 254 | + <row> |
| 255 | + <entry>3.0</entry> |
| 256 | + <entry>PostgreSQL 7.4 and later</entry> |
| 257 | + </row> |
| 258 | + <row> |
| 259 | + <entry>2.0</entry> |
| 260 | + <entry>up to PostgreSQL 13</entry> |
| 261 | + <entry>See previous releases of |
| 262 | + the <productname>PostgreSQL</productname> documentation for |
| 263 | + details</entry> |
| 264 | + </row> |
| 265 | + </tbody> |
| 266 | + </tgroup> |
| 267 | + </table> |
| 268 | + </sect2> |
222 | 269 | </sect1>
|
223 | 270 |
|
224 | 271 | <sect1 id="protocol-flow">
|
|
0 commit comments