Re: Patch to fix search_path defencies with pg_bench

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, Greg Smith <gsmith(at)gregsmith(dot)com>, jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch to fix search_path defencies with pg_bench
Date: 2009-05-07 14:12:07
Message-ID: 1241705527.6109.188.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote:
> "Dickson S. Guedes" <listas(at)guedesoft(dot)net> writes:
> > Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu:
> >> Seems like the right policy for that is "run pgbench in its own
> >> database".
>
> > A text warning about this could be shown at start of pgbench if the
> > target database isn't named "pgbench", for examplo, or just some text
> > could be added to the docs.
>
> There already is a prominent warning in the pgbench docs:
>
> Caution
>
> pgbench -i creates four tables accounts, branches, history, and
> tellers, destroying any existing tables of these names. Be very
> careful to use another database if you have tables having these
> names!

Holy Handgrenade, what a huge footgun! It doesn't even have a
conceivable upside.

The table names "accounts" and "history" are fairly common and a caution
isn't a sufficient safeguard on production data. We know the manual
rarely gets read *after* a problem, let alone beforehand.

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.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2009-05-07 14:13:12 Re: Serializable Isolation without blocking
Previous Message Kevin Grittner 2009-05-07 14:07:01 Re: Serializable Isolation without blocking