Skip site navigation (1) Skip section navigation (2)

Re: Drop does not always drop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Badger <bbadger(at)openskills(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Drop does not always drop
Date: 2004-12-20 15:22:01
Message-ID: 19271.1103556121@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-novice
Bruce Badger <bbadger(at)openskills(dot)com> writes:
> I'm building a system in Smalltalk and using unit tests (SUnit)
> extensively.  The unit tests cover all model and persistence aspects of
> the system, and part of what they do is create and drop the tables in
> the system for each bunch of tests.  So, tables are being rapidly
> created and dropped.

> Sometimes, the drops don't work, and I get errors when I try and create
> the tables again like:

What this looks like to me is a race condition between multiple
instances of the same test, ie, two or more connections trying to create
identically-named tables at about the same time.  The "duplicate key"
error is really not possible if the problem is that "the drop didn't
work" --- that message can only come out if some other process creates a
conflicting entry between the point where we check for pre-existence of
the table (leading to the "relation already exists" error) and the point
where we physically install index entries for the table's catalog
entries.

So, check your control logic to see if it's scheduling concurrent copies
of the same test.

			regards, tom lane

In response to

Responses

pgsql-novice by date

Next:From: Devrim GUNDUZDate: 2004-12-20 15:24:20
Subject: Re: create user with password
Previous:From: sarlav kumarDate: 2004-12-20 15:18:42
Subject: create user with password

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group