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 b150118b2805e7cda2f375d313e769e7bde42daa..346112aba320b8c16a0da7a29a428519464d130a 100644 (file)
--- a/src/backend/utils/cache/relmapper.c
+++ b/src/backend/utils/cache/relmapper.c
@@ -941,12 +941,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);
    }