On Thu, May 7, 2009 at 10:12 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote: >> "Dickson S. Guedes" <lis...@guedesoft.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.
I bet it would be just as good and a lot simpler to do what someone suggested upthread, namely s/^/pgbench_/ ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
