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 по дате отправления: