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:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Using new copy libpq functions on a v2 protocol backend
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: locks in CREATE TRIGGER, ADD FK