Re: locks in CREATE TRIGGER, ADD FK - Mailing list pgsql-hackers
From | Neil Conway |
---|---|
Subject | Re: locks in CREATE TRIGGER, ADD FK |
Date | |
Msg-id | 4240C74A.1020201@samurai.com Whole thread Raw |
In response to | locks in CREATE TRIGGER, ADD FK (Neil Conway <neilc@samurai.com>) |
Responses |
Re: locks in CREATE TRIGGER, ADD FK
Re: locks in CREATE TRIGGER, ADD FK Re: locks in CREATE TRIGGER, ADD FK |
List | pgsql-hackers |
Neil Conway wrote: > AndrewSN pointed out on IRC that ALTER TABLE ... ADD FOREIGN KEY and > CREATE TRIGGER both acquire AccessExclusiveLocks on the table they are > adding triggers to (the PK table, in the case of ALTER TABLE). Is this > necessary? I don't see why we can't allow SELECT queries on the table to > proceed while the trigger is being added. Attached is a patch that changes both to use ShareRowExclusiveLock, and updates the documentation accordingly. I'll apply this later today, barring any objections. -Neil Index: doc/src/sgml/mvcc.sgml =================================================================== RCS file: /var/lib/cvs/pgsql/doc/src/sgml/mvcc.sgml,v retrieving revision 2.47 diff -c -r2.47 mvcc.sgml *** doc/src/sgml/mvcc.sgml 26 Feb 2005 18:37:17 -0000 2.47 --- doc/src/sgml/mvcc.sgml 23 Mar 2005 00:46:36 -0000 *************** *** 654,661 **** </para> <para> ! This lock mode is not automatically acquired by any ! <productname>PostgreSQL</productname> command. </para> </listitem> </varlistentry> --- 654,661 ---- </para> <para> ! Acquired by <command>CREATE TRIGGER</command> and <command>ALTER ! TABLE ADD FOREIGN KEY</command>. </para> </listitem> </varlistentry> Index: src/backend/commands/tablecmds.c =================================================================== RCS file: /var/lib/cvs/pgsql/src/backend/commands/tablecmds.c,v retrieving revision 1.148 diff -c -r1.148 tablecmds.c *** src/backend/commands/tablecmds.c 20 Mar 2005 22:00:52 -0000 1.148 --- src/backend/commands/tablecmds.c 23 Mar 2005 00:49:08 -0000 *************** *** 3829,3841 **** Oid constrOid; /* ! * Grab an exclusive lock on the pk table, so that someone doesn't ! * delete rows out from under us. (Although a lesser lock would do for ! * that purpose, we'll need exclusive lock anyway to add triggers to ! * the pk table; trying to start with a lesser lock will just create a ! * risk of deadlock.) */ ! pkrel = heap_openrv(fkconstraint->pktable, AccessExclusiveLock); /* * Validity and permissions checks --- 3829,3839 ---- Oid constrOid; /* ! * Grab a lock on the pk table, so that someone doesn't delete ! * rows out from under us; ShareRowExclusive should be good ! * enough. */ ! pkrel = heap_openrv(fkconstraint->pktable, ShareRowExclusiveLock); /* * Validity and permissions checks Index: src/backend/commands/trigger.c =================================================================== RCS file: /var/lib/cvs/pgsql/src/backend/commands/trigger.c,v retrieving revision 1.178 diff -c -r1.178 trigger.c *** src/backend/commands/trigger.c 20 Mar 2005 23:40:24 -0000 1.178 --- src/backend/commands/trigger.c 23 Mar 2005 00:49:53 -0000 *************** *** 87,93 **** ObjectAddress myself, referenced; ! rel = heap_openrv(stmt->relation, AccessExclusiveLock); if (stmt->constrrel != NULL) constrrelid = RangeVarGetRelid(stmt->constrrel, false); --- 87,98 ---- ObjectAddress myself, referenced; ! /* ! * We need to prevent concurrent CREATE TRIGGER commands, as well ! * as concurrent table modifications (INSERT, DELETE, UPDATE), so ! * ShareRowExclusive is sufficient. ! */ ! rel = heap_openrv(stmt->relation, ShareRowExclusiveLock); if (stmt->constrrel != NULL) constrrelid = RangeVarGetRelid(stmt->constrrel, false);
pgsql-hackers by date: