Commit624f155

committed

heap_update() must recheck tuple after unlocking and relocking buffer.

Bug found by Alvaro Herrera, fix suggested by Heikki Linnakangasand reviewed by Tom Lane.

1 parent269c5dd commit624f155Copy full SHA for 624f155

File tree

-1

lines changed

-1

lines changed

Lines changed: 4 additions & 1 deletion

Original file line number	Diff line number	Diff line change
`@@ -2645,13 +2645,16 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,`
`2645`	`2645`	`* visible while we were busy locking the buffer, or during some subsequent`
`2646`	`2646`	`* window during which we had it unlocked, we'll have to unlock and`
`2647`	`2647`	`* re-lock, to avoid holding the buffer lock across an I/O. That's a bit`
`2648`		`- * unfortunate, but hopefully shouldn't happen often.`
	`2648`	`+ * unfortunate, esepecially since we'll now have to recheck whether the`
	`2649`	`+ * tuple has been locked or updated under us, but hopefully it won't`
	`2650`	`+ * happen very often.`
`2649`	`2651`	`*/`
`2650`	`2652`	`if (vmbuffer==InvalidBuffer&&PageIsAllVisible(page))`
`2651`	`2653`	`{`
`2652`	`2654`	`LockBuffer(buffer,BUFFER_LOCK_UNLOCK);`
`2653`	`2655`	`visibilitymap_pin(relation,block,&vmbuffer);`
`2654`	`2656`	`LockBuffer(buffer,BUFFER_LOCK_EXCLUSIVE);`
	`2657`	`+gotol2;`
`2655`	`2658`	`}`
`2656`	`2659`
`2657`	`2660`	`/*`

Comments

(0)