mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Another fix to relmapper race condition.

Browse Source 
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
This commit is contained in:
Heikki Linnakangas 2021-06-24 11:19:03 +03:00
parent b6d8d2073f
commit 9b8ed0f52b
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/backend/utils/cache/relmapper.c vendored
View File

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