Re: Reducing some DDL Locks to ShareLock
От | Simon Riggs |
---|---|
Тема | Re: Reducing some DDL Locks to ShareLock |
Дата | |
Msg-id | 1223392348.4747.219.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Reducing some DDL Locks to ShareLock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing some DDL Locks to ShareLock
|
Список | pgsql-hackers |
On Tue, 2008-10-07 at 10:35 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On Tue, 2008-10-07 at 10:05 -0400, Robert Haas wrote: > >>> 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. > >> > >> Urk... this seems pretty undesirable. > > > OK, but please say what behaviour you would like in its place. > > I wonder whether this could be helped if we refactored pg_constraint. > The lack of a useful pkey for it has been annoying me for awhile, > and I think it stems from a misguided choice to put table and domain > constraints into the same catalog. Suppose that > > * table constraints go into pg_relation_constraint, with a unique key > on (conrelid, conname) > > * domain constraints go into pg_domain_constraint, with a unique key > on (contypid, conname) > > * pg_constraint can still exist as a union view, for client > compatibility > > Then the unique key would prevent concurrent creation of > identically-named constraints for the same relation. Sounds better. Doesn't make much sense as it is now. > I'm confused by your comment about inheritance --- what cases are > you thinking this would break? Well, I made the index unique and got a boat load of errors. I guess I might have misdiagnosed their cause. I'll have another look. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: