Everyone, We could use some help. Anyone's got an idea what could be causing the behavior described below?
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. > > Well, if you try the same thing with CREATE FUNCTION foo() RETURNS > persons_type AS $$ blah $$ LANGUAGE plpythonu; or some similar cases, > there is also no lock. You will notice that (some/many?) DDL statements > actually behave very poorly against concurrent other DDL. Against that > background, however, the real question is why the first case *does* > lock. I don't know. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
