Re: Drop does not always drop

Поиск
Список
Период
Сортировка
От Bruce Badger
Тема Re: Drop does not always drop
Дата
Msg-id 1103614522.24767.11.camel@orac.set.badgerse.com
обсуждение исходный текст
Ответ на Re: Drop does not always drop  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


Вложения

В списке pgsql-novice по дате отправления:

Предыдущее
От: Stefan Weiss
Дата:
Сообщение: Re: [PERFORM] Postgres version change - pg_dump
Следующее
От: "Marcin Gil"
Дата:
Сообщение: Re: pg_dumpall with oids/blobs