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

From Bruce Badger
Subject Re: Drop does not always drop
Date
Msg-id 1103614522.24767.11.camel@orac.set.badgerse.com
Whole thread Raw
In response to Re: Drop does not always drop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
On Tue, 2004-12-21 at 02:22, Tom Lane wrote:
> Bruce Badger <bbadger@openskills.com> writes:
> > 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.

Yes, it looked to me like a race condition somewhere.

As it happens, I wrote the PostgreSQL drivers for Smalltalk, so I was
able to easily add code to only allow one connection at a time.  Any
attempt to have more than one active connection would cause a walk-back
(stack dump).

I ran the test code again, and experienced exactly the same symptoms as
before (i.e. table drop appearing to work, but then hitting problem as
if the table had not been dropped) and the multi-connection trap did
*not* fire (i.e. there was never more than one connection at a time).

As it happens, this is reflected in the log I mentioned.  The trap does
confirm that only one connection is active at a time, though.

The log is 40k uncompressed, so I didn't want to post it here.  I'd be
delighted to email it along to anyone who is interested though (he
suggested hopefully).

Many thanks for the response, Tom.

All the best,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.com


Attachment

pgsql-novice by date:

Previous
From: Stefan Weiss
Date:
Subject: Re: [PERFORM] Postgres version change - pg_dump
Next
From: "Marcin Gil"
Date:
Subject: Re: pg_dumpall with oids/blobs