Hello Tom,
I agree that compatibility with protocol v2 (pg 7.4) is not an issue.
As Tom, I would not have bothered, though, however once it is there why
not?
As far as the patch goes --- I think that someday in the not too distant
feature we ought to rip out libpq's support for v2 protocol, which *would*
amount to a meaningful savings in code and maintenance effort. And then
we could look around for v2-related code in our clients and get rid of
that. But I'm not in favor of doing little bits of the latter before
we've done the former.
I'm fine with dropping support when it is done at libpq level, for
consistency.
Should the doc state that pgbench compatibility is ok from pg 8.0?
It'd definitely be a good idea to have a stated policy about what
the minimum supported server version is. psql, for instance, generally
works back to at least 7.0 (the oldest server version I've got in
captivity at the moment), but its describe.c functionality only goes
back to 7.4, as stated in the header for that file. I don't know
what a good cutoff for pgbench is, but we should figure that out
and document it.
Hmmm. There are several levels: protocol/libpq, and what you can put in a
pgbench initialization or script.
For the first part, it does not seem to use anything untoward, so probably
it should work with pretty old, although I have no simple way to test
much. It does not seem to use anything which did not exist in 2004
according to "libpq/exports.txt".
For the second one, UNLOGGED was introduced in 9.1, so running -i
--unlogged-tables will fail on 9.0, but very probably works without the
option. Similarly, TABLESPACE need 8.0, FIL.LFACTOR needs 8.2 and is
always used (FILLFACTOR=100). "DROP TABLE IF EXISTS" requires 8.2 as well.
So 8.2 is probably currently a minimal version for "pgbench -i"... thus
Tatsuo's patch is not an issue.
Now I could not even "initdb" a freshly compiled 8.[23] versions on my
ubuntu 18.4 laptop:-( When compiling 9.0 "*** The installed version of
Flex, /usr/bin/flex, is too old to use with PostgreSQL. *** Flex version
2.5.31 or later is required, but this is flex 2.6.4.". Ah ah, I like
autoconf soooooo much:-) I got tired and skipped to 9.3 and can confirm
that pgbench 10.4 works a postgres 9.3 server, for instance.
Basically Pgbench is really compatible with a given server version
depending on the options used, so asserting a compatibility level requires
some careful phrasing. Maybe something like that could be added to the
documentation:
"""
Pgbench is expected to work with all PostgreSQL supported versions at
the time it is released. Some options may work only with newer servers. It
may work with older version down to 8.2.
"""
See attached patch.
--
Fabien.
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 88cf8b3933..6fc9d53828 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -128,6 +128,13 @@ pgbench <optional> <replaceable>options</replaceable>
</optional> <replaceable>d
and <option>-f</option> (specify a custom script file).
See below for a full list.
</para>
+
+ <para>
+ <application>Pgbench</application> is expected to work with all PostgreSQL
+ supported versions at the time it is released.
+ Some options may require newer servers.
+ It may work with older version, down to 8.2.
+ </para>
</refsect1>
<refsect1>
