summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlvaro Herrera2015-05-18 20:44:21 +0000
committerAlvaro Herrera2015-05-18 20:44:21 +0000
commit850e1a566eb68b32df240c49843ac498603a11c8 (patch)
tree78c12faad440e523206fde18b39bc2dd7927d4fd
parent730912f9a3111ead7200756eca14fedf44a449e9 (diff)
Don't MultiXactIdIsRunning when in recovery
In 9.1 and earlier, it is possible for index_getnext() to try to examine a heap buffer for possible HOT-prune when in recovery; this causes a problem when a multixact is found in a tuple's Xmax, because GetMultiXactIdMembers refuses to run when in recovery, raising an error: ERROR: cannot GetMultiXactIdMembers() during recovery This can be solved easily by having MultiXactIdIsRunning always return false when in recovery, which is reasonable because a HOT standby cannot acquire further tuple locks nor update/delete tuples. (Note: it doesn't look like this specific code path has a problem in 9.2, because instead of doing HeapTupleSatisfiesUpdate directly, heap_hot_search_buffer uses HeapTupleIsSurelyDead instead. Still, there may be other paths affected by the same bug, for instance in pgrowlocks, and the multixact code hasn't changed; so apply the same fix throughout.) Apply this fix to 9.0 through 9.2. In 9.3 the multixact code has been changed completely and is no longer subject to this problem. Per report from Marko Tiikkaja, https://www.postgresql.org/message-id/54EB3283.2080305@joh.to Analysis by Andres Freund
-rw-r--r--src/backend/access/transam/multixact.c15
1 files changed, 15 insertions, 0 deletions
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 5875ca18270..5369dbae324 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -383,6 +383,21 @@ MultiXactIdIsRunning(MultiXactId multi)
debug_elog3(DEBUG2, "IsRunning %u?", multi);
+ /*
+ * During recovery, all multixacts can be considered not running: in
+ * effect, tuple locks are not held in standby servers, which is fine
+ * because the standby cannot acquire further tuple locks nor update/delete
+ * tuples.
+ *
+ * We need to do this first, because GetMultiXactIdMembers complains if
+ * called on recovery.
+ */
+ if (RecoveryInProgress())
+ {
+ debug_elog2(DEBUG2, "IsRunning: in recovery");
+ return false;
+ }
+
nmembers = GetMultiXactIdMembers(multi, &members);
if (nmembers < 0)