Commiteb3bd24

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 parentc78bb32 commiteb3bd24Copy full SHA for eb3bd24

File tree

-2

lines changed

-2

lines changed

Lines changed: 3 additions & 2 deletions

Original file line number	Diff line number	Diff line change
`@@ -949,12 +949,13 @@ relmap_redo(XLogReaderState *record)`
`949`	`949`	`* preserve files, either.`
`950`	`950`	`*`
`951`	`951`	`* There shouldn't be anyone else updating relmaps during WAL replay,`
`952`		`- * so we don't bother to take the RelationMappingLock. We would need`
`953`		`- * to do so if load_relmap_file needed to interlock against writers.`
	`952`	`+ * but grab the lock to interlock against load_relmap_file().`
`954`	`953`	`*/`
	`954`	`+LWLockAcquire(RelationMappingLock,LW_EXCLUSIVE);`
`955`	`955`	`write_relmap_file((xlrec->dbid==InvalidOid),&newmap,`
`956`	`956`	`false, true, false,`
`957`	`957`	`xlrec->dbid,xlrec->tsid,dbpath);`
	`958`	`+LWLockRelease(RelationMappingLock);`
`958`	`959`
`959`	`960`	`pfree(dbpath);`
`960`	`961`	`}`

Comments

(0)