From 1c563a2ae1c800c93fe5f41d0427e36bef874ba7 Mon Sep 17 00:00:00 2001
From: Simon Riggs <simon@2ndQuadrant.com>
Date: Mon, 3 Dec 2012 11:59:25 +0000
Subject: [PATCH] Clarify when to use PageSetLSN/PageGetLSN(). Update README to
 explain prerequisites for correct access to LSN fields of a page. Independent
 chunk removed from checksums patch to reduce size of patch.

---
 src/backend/access/transam/README | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README
index f8ebf5758f0..548ddbb4dd5 100644
--- a/src/backend/access/transam/README
+++ b/src/backend/access/transam/README
@@ -564,6 +564,14 @@ something like
 	if (BufferIsValid(buffer0))
 		UnlockReleaseBuffer(buffer0);
 
+Note that we must only use PageSetLSN/PageGetLSN() when we know the action
+is serialised. Only Startup process may modify data blocks during recovery,
+so Startup process may execute PageGetLSN() without fear of serialisation
+problems. All other processes must only call PageSet/GetLSN when holding
+either an exclusive buffer lock or a shared lock plus buffer header lock,
+or be writing the data block directly rather than through shared buffers
+while holding AccessExclusiveLock on the relation.
+
 Due to all these constraints, complex changes (such as a multilevel index
 insertion) normally need to be described by a series of atomic-action WAL
 records.  What do you do if the intermediate states are not self-consistent?
-- 
GitLab