Re: Review: Typed Table

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.