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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-08-29 14:35:42
Message-ID: alpine.DEB.2.21.1808291615280.14012@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Peter,

>> """
>> 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.
>> """
>
> It is generally expected (nowadays) that client programs work
> independent of the server version, unless restrictions are specifically
> documented (e.g., pg_dump) or there is some obvious feature dependency
> (e.g., unlogged tables).

Yep, that is somehow what I said in the mail.

> So the above paragraph does not add any useful information.

It tells that it will not work from 8.1 and below.

> Also, I don't find any reason why 8.2 is the cutoff, and saying that it
> may work down to 8.2 (implying that it may not) is content-free.

The "may" is because I could *not* test: I could not run a 8.2 on my
laptop, "initdb" fails on:

creating template1 database in <...>/src/test/regress/./tmp_check/data/base/1 ... ok
initializing pg_authid ... FATAL: wrong number of index expressions
STATEMENT: CREATE TRIGGER pg_sync_pg_database AFTER INSERT OR UPDATE OR DELETE ON pg_database FOR EACH STATEMENT EXECUTE PROCEDURE flatfile_update_trigger();

So I did not feel confident in saying that it would work for 8.2. That is
just me being precise:-)

As explained in the previous mail, pgbench "CREATE TABLE" always uses
"FILLFACTOR" which was introduced in 8.2, so it is sure to fail before
that.

What about:

"""
Pgbench requires a PostgreSQL version 8.2 or above server.
"""

Some information is provided...

I understood that Tom found that an explicit compatibility note would be
welcome, so I provided one. I'm also fine with saying nothing.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-08-29 14:39:42 Re: some more error location support
Previous Message Yugo Nagata 2018-08-29 14:25:28 Re: pg_verify_checksums -d option (was: Re: pg_verify_checksums -r option)