From 8b01a403c5cc4e070107bea04e8e285151a0a073 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 24 Jun 2021 11:19:03 +0300 Subject: [PATCH] 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 --- src/backend/utils/cache/relmapper.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c index e23730610b..e643e6abb3 100644 --- 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); }