Re: Removing useless \. at the end of copy in pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Removing useless \. at the end of copy in pgbench
Date: 2018-07-28 23:59:00
Message-ID: alpine.DEB.2.21.1807281630040.20629@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
pgbench-compat-1.patch text/plain 680 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-07-29 00:11:17 Re: Usability fail with psql's \dp command
Previous Message Michael Paquier 2018-07-28 23:19:11 Re: Problem while setting the fpw with SIGHUP