On Wed, 2008-06-04 at 16:33 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > We have > > * relhasindex (bool) set by CREATE INDEX but not unset by DROP INDEX > > * relhasrules (bool) > > * reltriggers (int2) set by CREATE and DROP, since its an integer > > Right. > > > If CREATE INDEX can take a Share lock and can update pg_class, why would > > it not be theoretically possible for CREATE TRIGGER? > > It's (probably) theoretically possible, if we replace reltriggers with a > bool that acts more like relhasindex, ie it's a hint to go look in > pg_triggers.
Looking at this area of locking, I've noticed that the locks held by CREATE TRIGGER are more of a problem than might be apparent. * Locks held by CREATE TRIGGER are an issue for trigger-based replication systems, where triggers are frequently added and removed to various tables. * ALTER TABLE .. ADD FOREIGN KEY holds an AccessExclusiveveLock on *both* referencing and referenced tables. It does this because we must add triggers to both tables. So reducing the lock strength required by CREATE TRIGGER would also allow a reduction in lock strength for adding FKs. So useful steps will be to * refactor pg_class code so that CREATE TRIGGER uses an identical approach to CREATE INDEX * reduce lock strength for CREATE TRIGGER and ALTER TABLE ... ADD FOREIGN KEY so that it takes a ShareLock during ATAddForeignKeyConstraint() * look at how we can reduce lock strength for other ALTER TABLE subcommands. Not sure how yet. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
