Ooops, I broke initdb with that last patch.

That's what I get for not fully retesting the final version of the patch.
The replace_allowed cross-check needs an additional special case for
bootstrapping.

diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index e6fc6a005895c3e9b02bc630621030a599c3cadf..10d300a3e8804753794736d443bf32bbc6b86fbd 100644 (file)
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -181,13 +181,13 @@ do { \
                                           HASH_ENTER, &found); \
    if (found) \
    { \
-       /* this can happen, see comments in RelationBuildDesc */ \
+       /* see comments in RelationBuildDesc and RelationBuildLocalRelation */ \
        Relation _old_rel = hentry->reldesc; \
        Assert(replace_allowed); \
        hentry->reldesc = (RELATION); \
        if (RelationHasReferenceCountZero(_old_rel)) \
            RelationDestroyRelation(_old_rel, false); \
-       else \
+       else if (!IsBootstrapProcessingMode()) \
            elog(WARNING, "leaking still-referenced relcache entry for \"%s\"", \
                 RelationGetRelationName(_old_rel)); \
    } \
@@ -2861,9 +2861,15 @@ RelationBuildLocalRelation(const char *relname,
    RelationInitPhysicalAddr(rel);
 
    /*
-    * Okay to insert into the relcache hash tables.
+    * Okay to insert into the relcache hash table.
+    *
+    * Ordinarily, there should certainly not be an existing hash entry for
+    * the same OID; but during bootstrap, when we create a "real" relcache
+    * entry for one of the bootstrap relations, we'll be overwriting the
+    * phony one created with formrdesc.  So allow that to happen for nailed
+    * rels.
     */
-   RelationCacheInsert(rel, false);
+   RelationCacheInsert(rel, nailit);
 
    /*
     * Flag relation as needing eoxact cleanup (to clear rd_createSubid). We