|
22 | 22 | <productname>PostgreSQL</productname> version 18. The server and the libpq
|
23 | 23 | client library are backwards compatible with protocol version 3.0,
|
24 | 24 | implemented in <productname>PostgreSQL</productname> 7.4 and later.
|
25 |
| - For descriptions 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 | 25 | </para>
|
51 | 26 |
|
52 | 27 | <para>
|
|
212 | 187 | server versions; the text format is usually the more portable choice.
|
213 | 188 | </para>
|
214 | 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. However, for |
| 196 | + backwards compatibility with old server versions and middleware that don't |
| 197 | + support the version negotiation yet, libpq still uses protocol version 3.0 |
| 198 | + by default. |
| 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> |
215 | 269 | </sect1>
|
216 | 270 |
|
217 | 271 | <sect1 id="protocol-flow">
|
|
0 commit comments