Yeah, chances are that someone is going to make a change that will
require for example 8.4, and nobody would update this because the
differences between 8.2 and 8.4 are long forgotten.
It seems there is more enthusiasm on the side of not documenting it, so
I'll close this commit fest entry.
On 30/08/2018 08:39, Peter Eisentraut wrote:
> On 29/08/2018 21:48, Andres Freund wrote:
>> I'd vote for not adding it. It seems almost guaranteed to get out of
>> date without anybody noticing so. Maybe that's overly pragmatic, but I
>> really can't see the harm of not documenting which precise
On 29/08/2018 21:48, Andres Freund wrote:
> I'd vote for not adding it. It seems almost guaranteed to get out of
> date without anybody noticing so. Maybe that's overly pragmatic, but I
> really can't see the harm of not documenting which precise ancient
> version pgbench doesn't support anymore.
On 2018-08-29 21:42:42 +0200, Fabien COELHO wrote:
>
> Hello,
>
> > 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
> > welcom
Hello,
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.
Here is a patch with the following
The "may" is because I could *not* test:
Works for me with 8.2.
Thanks for the confirmation.
Earlier branches fail immediately: dropping old tables... ERROR:
syntax error at or near "exists" LINE 1: drop table if exists
pgbench_accounts, pgbench_branches, pgb...
^
Fabien COELHO writes:
>> 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:
Works for me with 8.2. Earlier branches fail immediately:
dropping old tables...
ERRO
On 2018-Aug-29, Fabien COELHO wrote:
> 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 express
On 08/29/2018 10:35 AM, Fabien COELHO wrote:
> 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
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 serv
On 29/07/2018 01:59, Fabien COELHO wrote:
> """
> 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 pr
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, w
Fabien COELHO writes:
> 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
Hello Tatsuo-san,
If we want to support pre 7.4 backend (which only supports the version
2 protocol), we could test the current protocol version and decide
whether we should send out "\." or not, but I doubt it's necessary.
Comments?
Code tested, ok.
I agree that compatibility with protoco
> Tatsuo Ishii writes:
>> While populating pgbench_account table by using COPY FROM STDIN,
>> pgbench sends out "\." at the end of the copy data. However this is
>> only necessary in the version 2 of frontend/backend protocol (i.e. the
>> version 3 protocol does not need it). I think we can safely
Tatsuo Ishii writes:
> While populating pgbench_account table by using COPY FROM STDIN,
> pgbench sends out "\." at the end of the copy data. However this is
> only necessary in the version 2 of frontend/backend protocol (i.e. the
> version 3 protocol does not need it). I think we can safely remov
While populating pgbench_account table by using COPY FROM STDIN,
pgbench sends out "\." at the end of the copy data. However this is
only necessary in the version 2 of frontend/backend protocol (i.e. the
version 3 protocol does not need it). I think we can safely remove the
code to save a few CPU c
17 matches
Mail list logo
