Re: pgbench / compatibility with old(er) releases - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: pgbench / compatibility with old(er) releases
Date
Msg-id 5210F6D1.1030203@fuzzy.cz
Whole thread Raw
In response to Re: pgbench / compatibility with old(er) releases  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 18.8.2013 17:54, Tom Lane wrote:
> 
> TBH this seems like way too much cruft to be added in support of what
> are after all *unsupported* releases.  And how far back do we stop,
> anyway?
> 
> I'd suggest you test all the branches with the newest pgbench
> version that happens to work with the oldest branch you care about.

That won't give me the 9.3-only features (that I really want/need).

> Having said that, it seems like (a) could be fixed with about a
> one-line change, if we simply made it not add the "with
> (fillfactor=%d)" clause when fillfactor was at 100.  And I'm not

Yeah, that seems line a nice solution - no additional option.

Another solution is to use custom scripts, and only use pgbench to
execute them. That'd solve the IF EXISTS problem too.

> clear why (b) is a problem; libpq already takes care of suppressing
> application_name when connecting to old servers.

Hmmm, I'm getting this in the log (when connection to 8.0.0):
 FATAL:  unrecognized configuration parameter "application_name"

but it seems to be working. I'm wondering if FATAL is appropriate here.

Tomas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Feature Request on Extensions
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: CREATE FUNCTION .. SET vs. pg_dump