Re: Drop does not always drop - Mailing list pgsql-novice

From Tom Lane
Subject Re: Drop does not always drop
Date
Msg-id 19271.1103556121@sss.pgh.pa.us
Whole thread Raw
In response to Drop does not always drop  (Bruce Badger <bbadger@openskills.com>)
Responses Re: Drop does not always drop  (Bruce Badger <bbadger@openskills.com>)
List pgsql-novice
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

pgsql-novice by date:

Previous
From: sarlav kumar
Date:
Subject: create user with password
Next
From: Devrim GUNDUZ
Date:
Subject: Re: create user with password