Date: Mon, 18 May 2015 13:48:03 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Marko Tiikkaja <marko@joh.to>
Cc: Andres Freund <andres@2ndquadrant.com>,
 hackers <pgsql-hackers@postgresql.org>
Subject: Re: ERROR:  cannot GetMultiXactIdMembers() during recovery
Message-ID: <20150518164803.GP2523@alvh.no-ip.org>
References: <54EB3283.2080305@joh.to>
 <20150223141300.GB30784@awork2.anarazel.de>
 <5555F1E2.5080104@joh.to>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="aF3LVLvitz/VQU3c"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5555F1E2.5080104@joh.to>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--aF3LVLvitz/VQU3c
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Marko Tiikkaja wrote:
> Hi hackers,
> 
> Any chance to get this fixed in time for 9.1.16?

I hope you had pinged some days earlier.  Here's a patch, but I will
wait until this week's releases have been tagged before pushing.

I checked 9.2, and it doesn't look like it's subject to the same
problem: instead of HeapTupleSatisfiesVacuum, it uses
HeapTupleIsSurelyDead in the equivalent place.  Still, I think it's
saner to apply the same bug because as Andres notes the problem might
still be present in pgrowlocks and who knows what else.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--aF3LVLvitz/VQU3c
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="multixact-in-recovery.patch"

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 476c53d..b90c110 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)

--aF3LVLvitz/VQU3c
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--aF3LVLvitz/VQU3c--