From f30c76ce8de6a3d9e79367112a9287b576c9e9cd Mon Sep 17 00:00:00 2001 From: Neil Conway Date: Wed, 23 Mar 2005 07:44:57 +0000 Subject: Adjust CREATE TRIGGER and ALTER TABLE ... ADD FOREIGN KEY to acquire ExclusiveLock rather than AccessExclusiveLock. This will allow concurrent SELECT queries to proceed on the table. Per discussion with Andrew at SuperNews. --- src/backend/commands/trigger.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'src/backend/commands/trigger.c') diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c index fd7d9afb836..55333e1f4f1 100644 --- a/src/backend/commands/trigger.c +++ b/src/backend/commands/trigger.c @@ -7,7 +7,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/commands/trigger.c,v 1.178 2005/03/20 23:40:24 neilc Exp $ + * $PostgreSQL: pgsql/src/backend/commands/trigger.c,v 1.179 2005/03/23 07:44:57 neilc Exp $ * *------------------------------------------------------------------------- */ @@ -87,7 +87,14 @@ CreateTrigger(CreateTrigStmt *stmt, bool forConstraint) ObjectAddress myself, referenced; - rel = heap_openrv(stmt->relation, AccessExclusiveLock); + /* + * We need to prevent concurrent CREATE TRIGGER commands, as well + * as concurrent table modifications (INSERT, DELETE, UPDATE), so + * acquire an ExclusiveLock -- it should be fine to allow SELECTs + * to proceed. We could perhaps acquire ShareRowExclusiveLock, but + * there seems little gain in allowing SELECT FOR UPDATE. + */ + rel = heap_openrv(stmt->relation, ExclusiveLock); if (stmt->constrrel != NULL) constrrelid = RangeVarGetRelid(stmt->constrrel, false); -- cgit v1.2.3