Re: Drop does not always drop

Bruce Badger <bbadger@openskills.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