Re: 8.4.1 ubuntu karmic slow createdb

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Nikolas Everett <nik9000(at)gmail(dot)com>
Cc: "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Michael Clemmons <glassresistor(at)gmail(dot)com>
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Date: 2009-12-11 22:12:45
Message-ID: C74803DD.1B1BF%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


On 12/11/09 1:57 PM, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> wrote:

>
> This is my big issue. dropping / creating databases for unit tests is
> overkill. Running any DDL at all for a unit test seems wrong to me
> too. Insert a row if you need it, MAYBE. Unit tests should work with
> a test database that HAS the structure and database already in place.
>
> What happens if your unit tests get lose in production and drop a
> database, or a table. Not good.
>

Production should not have a db with the same username/pw combination as dev
boxes and unit tests . . .

Unfortunately, unit-like (often more than a 'unit') tests can't always rely
on a test db being already set up. If one leaves any cruft around, it might
break later tests later on non-deterministically. Automated tests that
insert data are absolutely required somewhere if the application inserts
data.

The best way to do this in postgres is to create a template database from
scratch with whatever DDL is needed at the start of the run, and then create
and drop db's as copies of that template per test or test suite.

So no, its not overkill at all IMO. I do wish to avoid it, and ideally all
tests clean up after themselves, but in practice this does not happen and
results in hard to track down issues where test X fails because of something
that any one of tests A to W did (all of which pass), often wasting time of
the most valuable developers -- those who know the majority of the system
well enough to track down such issues across the whole system.

One thing to consider, is putting this temp database in a RAMFS, or ramdisk
since postgres does a lot of file creates and fsyncs when cloning a db from
a template. For almost all such test db's the actual data is small, but the
# of tables is large.

> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Marlowe 2009-12-11 22:12:47 Re: 8.4.1 ubuntu karmic slow createdb
Previous Message Scott Mead 2009-12-11 21:59:43 Re: 8.4.1 ubuntu karmic slow createdb

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2009-12-11 22:12:47 Re: 8.4.1 ubuntu karmic slow createdb
Previous Message Scott Mead 2009-12-11 21:59:43 Re: 8.4.1 ubuntu karmic slow createdb