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

Re: Drop does not always drop

From: Bruce Badger <bbadger(at)openskills(dot)com>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: Drop does not always drop
Date: 2004-12-21 07:35:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
On Tue, 2004-12-21 at 02:22, Tom Lane wrote:
> Bruce Badger <bbadger(at)openskills(dot)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,
Make the most of your skills - with OpenSkills

In response to

pgsql-novice by date

Next:From: Marcin GilDate: 2004-12-21 07:36:47
Subject: Re: pg_dumpall with oids/blobs
Previous:From: IainDate: 2004-12-21 07:09:55
Subject: Re: [PERFORM] Postgres version change - pg_dump

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