Re: Patch to fix search_path defencies with pg_bench - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to fix search_path defencies with pg_bench
Date
Msg-id 20631.1241714848@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to fix search_path defencies with pg_bench  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Patch to fix search_path defencies with pg_bench  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Thu, 2009-05-07 at 11:14 -0400, Robert Haas wrote:
>>> We should check they are the correct tables before we just drop them.
>>> Perhaps check for the comment "Tables for pgbench application. Not
>>> production data" on the tables, which would be nice to add anyway.
>> 
>> I bet it would be just as good and a lot simpler to do what someone
>> suggested upthread, namely s/^/pgbench_/

> Running pgbench has become more popular now, with various people
> recommending running it on every system to test performance. I don't
> disagree with that recommendation, but I've had problems myself with a
> similar issue - hence earlier patch to prevent pgbench running a
> complete database VACUUM before every test run.

Well, pgbench has been coded this way since forever and we've only seen
this one report of trouble.  Still, I can't object very hard to renaming
the tables to pgbench_accounts etc --- it's a trivial change and the
only thing it could break is custom pgbench scenarios that rely on the
default scenario's tables, which there are probably not many of.

So do we have consensus on dropping the "SET search_path" and renaming
the tables?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench
Next
From: Tom Lane
Date:
Subject: Re: Patch to fix search_path defencies with pg_bench