Avoid retaining multiple relation locks in RangeVarGetRelid.
authorRobert Haas <rhaas@postgresql.org>
Sat, 12 Nov 2011 06:22:45 +0000 (01:22 -0500)
committerRobert Haas <rhaas@postgresql.org>
Sat, 12 Nov 2011 06:22:45 +0000 (01:22 -0500)
If it turns out we've locked the wrong OID, release the old lock.  In
most cases, it's pretty harmless to retain the extra lock, but this
seems tidier and avoids using lock table slots unnecessarily.

Per discussion with Tom Lane.

src/backend/catalog/namespace.c

index fcc90fed5fd16eaca06a31f05f9f827d388bc268..6d4d4b1cccf765cb22692e3d1b68db91eacaf13c 100644 (file)
@@ -322,9 +322,18 @@ RangeVarGetRelid(const RangeVar *relation, LOCKMODE lockmode, bool missing_ok,
         * If, upon retry, we get back the same OID we did last time, then
         * the invalidation messages we processed did not change the final
         * answer.  So we're done.
+        *
+        * If we got a different OID, we've locked the relation that used to
+        * have this name rather than the one that does now.  So release
+        * the lock.
         */
-       if (retry && relId == oldRelId)
-           break;
+       if (retry)
+       {
+           if (relId == oldRelId)
+               break;
+           if (OidIsValid(oldRelId))
+               UnlockRelationOid(oldRelId, lockmode);
+       }
 
        /*
         * Lock relation.  This will also accept any pending invalidation