Re: Reducing some DDL Locks to ShareLock

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing some DDL Locks to ShareLock
Date: 2008-10-07 11:32:53
Message-ID: 1223379173.4747.145.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Tue, 2008-10-07 at 07:21 +0100, Simon Riggs wrote:

> It was an excellent question because that aspect isn't handled correctly
> in the enclosed patch for subcommands, other than index-creating
> constraints.
>
> My main focus is on these commands
> * CREATE TRIGGER
> * ALTER TABLE .. ADD PRIMARY KEY
> * ALTER TABLE .. ADD FOREIGN KEY
* CREATE RULE

> because those are the most painful ones. We could make it work against
> more, but we'd need to rewrite lots and lots of catalog update code.

OK, patch updated, tested, working.

Points of note.

1. I've left the infrastructure there for further changes, but we can
rip that out if desired.

2. Also need to decide whether we want pg_class.reltriggers as int2 (as
implemented here) or switch to relhastriggers as boolean.

3. The patch introduces a slight weirdness: if you create two FKs on the
same column at the same time you end up with two constraints with
identical names. Drop constraint then removes them both, though in other
respects they are both valid, just not uniquely. CREATE INDEX avoids
this by way of the unique index on relname. The equivalent index on
pg_constraint is not unique, though *cannot* be made unique without
breaking some corner cases of table inheritance.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Attachment Content-Type Size
ddl_lock_reduce.v5.patch text/x-patch 49.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-10-07 12:30:57 Re: Reducing some DDL Locks to ShareLock
Previous Message Heikki Linnakangas 2008-10-07 11:16:06 Re: Weird behaviour with ALTER TABLE ... SET TABLESPACE ... statement