Re: pgbench / compatibility with old(er) releases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench / compatibility with old(er) releases
Date: 2013-08-18 15:54:19
Message-ID: 21483.1376841259@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> I do understand the versions up to 8.3 are unsupported (or soon will
> be), but I think it's handy to be able to run current pgbench on those
> versions. So I propose to:

> (a) add --no-fillfactor that actually disables adding it to the
> CREATE TABLE (now it adds default 100)

> (b) add --no-appname that disables adding it to the connection (BTW
> why not to allow custom appname? I'm thinking about multiple
> pgbench instances running at the same time, or so, but on second
> thought I've never done that.)

> (c) do not use "IF EXISTS" but do that the old way (check if the
> table exists in a separate command)

> Opinions? Objections?

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.

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 clear why (b) is a problem;
libpq already takes care of suppressing application_name when connecting
to old servers.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-08-18 16:21:58 Re: Feature Request on Extensions
Previous Message Tom Lane 2013-08-18 15:40:47 Re: CREATE FUNCTION .. SET vs. pg_dump