Commit9b8ed0f

committed

Another fix to relmapper race condition.

In previous commit, I missed that relmap_redo() was also not acquiring theRelationMappingLock. 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

1 parentb6d8d20 commit9b8ed0fCopy full SHA for 9b8ed0f

File tree

-2

lines changed

-2

lines changed

Lines changed: 3 additions & 2 deletions

Original file line number	Diff line number	Diff line change
`@@ -1030,12 +1030,13 @@ relmap_redo(XLogReaderState *record)`
`1030`	`1030`	`* preserve files, either.`
`1031`	`1031`	`*`
`1032`	`1032`	`* There shouldn't be anyone else updating relmaps during WAL replay,`
`1033`		`- * so we don't bother to take the RelationMappingLock. We would need`
`1034`		`- * to do so if load_relmap_file needed to interlock against writers.`
	`1033`	`+ * but grab the lock to interlock against load_relmap_file().`
`1035`	`1034`	`*/`
	`1035`	`+LWLockAcquire(RelationMappingLock,LW_EXCLUSIVE);`
`1036`	`1036`	`write_relmap_file((xlrec->dbid==InvalidOid),&newmap,`
`1037`	`1037`	`false, true, false,`
`1038`	`1038`	`xlrec->dbid,xlrec->tsid,dbpath);`
	`1039`	`+LWLockRelease(RelationMappingLock);`
`1039`	`1040`
`1040`	`1041`	`pfree(dbpath);`
`1041`	`1042`	`}`

Comments

(0)