From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Subject: | Re: Review: Typed Table |
Date: | 2010-01-28 09:21:08 |
Message-ID: | 4B615704.9020501@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> 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.
Types are cached in typcache. At the first CREATE TABLE, the type is not
in cache, and lookup_type_cache() (by the call to
lookup_rowtype_tupdesc() in transformOfType()) calls relation_open()
which blocks. On the second call, however, it's already in the cache,
and relation_open is not called.
ISTM you should explicitly grab a lock on the of-type at some point, to
make sure it doesn't get dropped while you're busy creating the table.
How do we protect against that for the types used in columns? For
example, if you do "CREATE TABLE (foo mytype)", and someone tries to
"drop mytype" simultaneously?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Takahiro Itagaki | 2010-01-28 09:21:43 | Re: Largeobject Access Controls (r2460) |
Previous Message | Tim Bunce | 2010-01-28 09:01:49 | Re: Add on_perl_init and proper destruction to plperl [PATCH] |