Put a CHECK_FOR_INTERRUPTS call into the loops that try to find a unique new

OID or new relfilenode.  If the existing OIDs are sufficiently densely
populated, this could take a long time (perhaps even be an infinite loop),
so it seems wise to allow the system to respond to a cancel interrupt here.
Per a gripe from Jacky Leng.

Backpatch as far as 8.1.  Older versions just fail on OID collision,
instead of looping.

diff --git a/src/backend/catalog/catalog.c b/src/backend/catalog/catalog.c
index 69313ea86a2e1816b7d6c24d2a1ccf5352b0ab7b..f490817812228704b8037aaf3db3299f1ba44426 100644 (file)
--- a/src/backend/catalog/catalog.c
+++ b/src/backend/catalog/catalog.c
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/catalog/catalog.c,v 1.64 2005/10/15 02:49:12 momjian Exp $
+ *       $PostgreSQL: pgsql/src/backend/catalog/catalog.c,v 1.64.2.1 2008/02/20 17:44:26 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -301,6 +301,8 @@ GetNewOidWithIndex(Relation relation, Relation indexrel)
        /* Generate new OIDs until we find one not in the table */
        do
        {
+               CHECK_FOR_INTERRUPTS();
+
                newOid = GetNewObjectId();
 
                ScanKeyInit(&key,
@@ -349,6 +351,8 @@ GetNewRelFileNode(Oid reltablespace, bool relisshared, Relation pg_class)
 
        do
        {
+               CHECK_FOR_INTERRUPTS();
+
                /* Generate the OID */
                if (pg_class)
                        rnode.relNode = GetNewOid(pg_class);