Re: Removing useless \. at the end of copy in pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Removing useless \. at the end of copy in pgbench
Date
Msg-id alpine.DEB.2.21.1807281630040.20629@lancre
Whole thread Raw
In response to Re: Removing useless \. at the end of copy in pgbench  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing useless \. at the end of copy in pgbench  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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.
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Problem while setting the fpw with SIGHUP
Next
From: Fabien COELHO
Date:
Subject: Re: Usability fail with psql's \dp command