Peter Eisentraut escribió: > Everyone, > > We could use some help. Anyone's got an idea what could be causing the > behavior described below?
I wonder if the problem is that you're missing a recheck on the type's existence after you've grabbed the lock on it, similar to what shdepLockAndCheckObject does. Maybe the second attempt to create the table doesn't block because pg_depends contents are different? It seems very strange. > On mån, 2010-01-25 at 21:45 +0200, Peter Eisentraut wrote: > > On tis, 2010-01-19 at 01:01 +0900, Hitoshi Harada wrote: > > > * Conflict between transactions > > > I'm not sure if this is related with the patch but I met this situation; > > > > > > A: regression=# create type persons_type as (name text, bdate date); > > > A: CREATE TYPE > > > > > > A: regression=# begin; > > > A: BEGIN > > > > > > A: regression=# drop type persons_type; > > > A: DROP TYPE > > > > > > B: regression=# create table persons of persons_type; (LOCK) > > > A: regression=# rollback; > > > A: ROLLBACK > > > B: CREATE TABLE > > > > > > B: regression=# drop table persons; > > > B: DROP TABLE > > > > > > A: regression=# begin; > > > A: BEGIN > > > > > > A: regression=# drop type persons_type; > > > A: DROP TYPE > > > > > > B: regression=# create table persons of persons_type; (NO LOCK) > > > B: CREATE TABLE > > > > > > A: regression=# commit; > > > A: COMMIT > > > > > > B: regression=# select 'persons_type'::regtype; > > > B: ERROR: type "persons_type" does not exist > > > B: LINE 1: select 'persons_type'::regtype; > > > > > > I have at all no idea why the second create table doesn't lock. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
