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);
        }