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.