Another fix to relmapper race condition.

In previous commit, I missed that relmap_redo() was also not acquiring the
RelationMappingLock. Thanks to Thomas Munro for pointing that out.

Backpatch-through: 9.6, like previous commit.
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com

diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c
index 34363b70c2019494f21f287bf2f6d311f29a35d5..a6e38adce307d4020800fdc8ae297ba0aab49bf3 100644 (file)
--- a/src/backend/utils/cache/relmapper.c
+++ b/src/backend/utils/cache/relmapper.c
@@ -1030,12 +1030,13 @@ relmap_redo(XLogReaderState *record)
         * preserve files, either.
         *
         * There shouldn't be anyone else updating relmaps during WAL replay,
-        * so we don't bother to take the RelationMappingLock.  We would need
-        * to do so if load_relmap_file needed to interlock against writers.
+        * but grab the lock to interlock against load_relmap_file().
         */
+       LWLockAcquire(RelationMappingLock, LW_EXCLUSIVE);
        write_relmap_file((xlrec->dbid == InvalidOid), &newmap,
                          false, true, false,
                          xlrec->dbid, xlrec->tsid, dbpath);
+       LWLockRelease(RelationMappingLock);
 
        pfree(dbpath);
    }