Re: Patch to fix search_path defencies with pg_bench

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch to fix search_path defencies with pg_bench
Дата
Msg-id 20631.1241714848@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch to fix search_path defencies with pg_bench  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Patch to fix search_path defencies with pg_bench  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Aidan Van Dyk
Дата:
Сообщение: Re: Patch to fix search_path defencies with pg_bench
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Patch to fix search_path defencies with pg_bench