Обсуждение: BUG #5621: Insufficient locking of dependent objects

The following bug has been logged online:

Bug reference:      5621
Logged by:          Caleb Welton
Email address:      cwelton@greenplum.com
PostgreSQL version: 9.1devel
Operating system:   OSX 10.6.4
Description:        Insufficient locking of dependent objects
Details:

There is a general class of concurrency bugs related to insufficient
locking
of dependent objects.  This can occur with just about any inter-object
dependency that exists in the system:

  Creating a table while dropping the schema it is in
  Creating a table while dropping a type it depends on
  Creating a function while dropping the language
  Creating an aggregate while dropping the transition function.
  Etc.

Here are two cases that represent the class of problems:


1) Table/Schema dependencies:

Session 1:
  CREATE SCHEMA DROPME;
  BEGIN;
  CREATE TABLE DROPME.TEST(a int);

Session 2:
  DROP SCHEMA DROPME;

Session 1:
  COMMIT;

  SELECT relname
  FROM pg_class c
  LEFT OUTER JOIN pg_namespace n
    ON (n.oid = c.relnamespace)
  WHERE n.oid is null;


Expected output of final query is zero rows (every table should have a
schema)
actual output is:

 relname
---------
 test
(1 row)


2) Table/Type dependencies

Session 1:
  CREATE TYPE dropme as (a int, b int);
  BEGIN;
  CREATE TABLE test(a dropme);

Session 2:
  DROP TYPE dropme;

Session 1:
  COMMIT;
  SELECT * FROM test;

Output of final select is:

ERROR:  cache lookup failed for type 16390

Problem exists in all versions of Postgtres from at least 8.2 through 9.1
devel.

On Tue, Aug 17, 2010 at 2:15 PM, Caleb Welton <cwelton@greenplum.com> wrote:
> There is a general class of concurrency bugs related to insufficient
> locking
> of dependent objects. =A0This can occur with just about any inter-object
> dependency that exists in the system:
>
> =A0Creating a table while dropping the schema it is in
> =A0Creating a table while dropping a type it depends on
> =A0Creating a function while dropping the language
> =A0Creating an aggregate while dropping the transition function.
> =A0Etc.

More specifically, I think the bug is that we don't really do much
locking on database objects other than tables.  This would be good to
fix, but probably we'd need to start by coming up with a coherent
overall plan.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company