[PATCH] Send numeric version to clients
От | Craig Ringer |
---|---|
Тема | [PATCH] Send numeric version to clients |
Дата | |
Msg-id | CAMsr+YGtwgpa-MZH1suehvTxDXOZB7U+DC0=qyCG9j02je1pWQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: [PATCH] Send numeric version to clients
|
Список | pgsql-hackers |
Hi all It's recently been observed[1] that the 10.0 version scheme change has affected PostGIS, which relies on parsing the server version string and broke when faced with a string like "10.0devel" since it expected a minor version. In that thread Tom points out [2] that they should be using PG_VERSION_NUM from the Makefile, or PG_CATALOG_VERSION from the headers. The same sort of problems apply to network clients, but network clients don't currently get that option because we only send server_version on the wire in the startup packet. We don't send server_version_num. It'll be immediately useful to have this since clients can test for it, use it if there, and fall back to their old version parsing code if there's no server_version_num. Version 10.0 is the perfect time to do this since many clients will need to update their version handling anyway, and we can just tell them to use server_version_num now. I'm a PgJDBC committer (albeit largely inactive lately), so I'm thoroughly familiar with at least one client, and I'd really like to be able to have PgJDBC able to prefer server_version_num. That's how I originally started looking at this. Also, clients relying on server_version makes configure's --with-extra-version nearly unusable in practice since if you build Pg 9.4.9-mypatch a bunch of clients fall over, as I discovered when working on BDR. I'm not convinced by the cost concerns that originally caused it not to be made GUC_REPORT [3], or at least that they still apply today. Since that change 10 years ago networks have changed a lot. More significantly we've since added both IntervalStyle ([4], df7641e2, Ron Mayer / Tom) and application_name ([5], 59ed94ad, Marko Kreen / Tom) as GUC_REPORT params. The startup packet is 331 bytes on my system, with a short application_name 'psql', short username 'craig', etc. Adding server_version_num would push it up ~26 bytes to ~357, a 7% increase on a packet we send once at connection establishment. Given that network performance is overwhelmingly dominated by round-trip costs even on fast local networks this is going to be practically undetectable. A minimal connect-and-disconnect psql session with no SSL exchanges 14 packets of 1363 bytes (TCP level), of which 670 bytes are server -> client. So that's a 4% increase on the network size of the most utterly trivial conversation possible, with zero new packets and zero new round trips. Unsurprisingly the pgbench effects are undetectable. Compare that to the effects of [6] pipelining work on the protocol, where I got speedups of 300x or more by tackling round trip costs. Can we please send server_version_num on the wire for 10.0? Patches attached. (BTW, I noticed while prepping that patch that we have identically duplicated docs for GUC_REPORT params in protocol.sgml and libpq.sgml.) [1] https://www.postgresql.org/message-id/000001d2014c$f84b9190$e8e2b4b0$@pcorp.us [2] https://www.postgresql.org/message-id/1585.1472410329@sss.pgh.pa.us [3] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e35ea51 [4] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=df7641e2 [5] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=59ed94ad [6] https://commitfest.postgresql.org/10/634/ -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: