postgres.git / summary / log / commit / refs

commit    97ff2a5645227d73c222373832ffb3bf9470ca73
Author:   Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:     Mon May 18 20:44:21 2015 +0000
First released in: 9.0.20, 9.1.16, 9.2.11

    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


 src/backend/access/transam/multixact.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 05f00c3c96e..83b4d432728 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -382,6 +382,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)


[parent: 520fecfae568]