Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WUc6S-0003gz-9g for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Mar 2014 13:18:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WUc6R-0001za-OE for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Mar 2014 13:18:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WUc6P-0001xX-Fk for pgsql-hackers@postgresql.org; Mon, 31 Mar 2014 13:18:13 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WUc6M-00080Y-QS for pgsql-hackers@postgresql.org; Mon, 31 Mar 2014 13:18:13 +0000 Received: from intern.anarazel.de (p54AF498E.dip0.t-ipconnect.de [84.175.73.142]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 7997F4E8003; Mon, 31 Mar 2014 15:18:09 +0200 (CEST) Date: Mon, 31 Mar 2014 15:18:07 +0200 From: Andres Freund To: Stephen Frost Cc: Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: MultiXactId error after upgrade to 9.3.4 Message-ID: <20140331131807.GC18358@alap3.anarazel.de> References: <20140330040029.GY4582@tamriel.snowman.net> <20140330141135.GA4582@tamriel.snowman.net> <20140330185349.GD4582@tamriel.snowman.net> <20140331115452.GT9567@eldon.alvh.no-ip.org> <20140331115713.GA18358@alap3.anarazel.de> <20140331121912.GU9567@eldon.alvh.no-ip.org> <20140331123030.GB18358@alap3.anarazel.de> <20140331130215.GV9567@eldon.alvh.no-ip.org> <20140331130908.GO4582@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140331130908.GO4582@tamriel.snowman.net> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2014-03-31 09:09:08 -0400, Stephen Frost wrote: > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > > I guess I wasn't expecting that too-old values would last longer than a > > full wraparound cycle. Maybe the right fix is just to have the second > > check also conditional on allow_old. > > I don't believe this was a wraparound case. Could you show pg_controldata from the old cluster? > > Anyway, it's not clear to me why this database has a multixact value of > > 6 million when the next multixact value is barely above one million. > > Stephen said a wraparound here is not likely. > > I don't think the xmax value is a multixact at all- I think it's > actually a regular xid, but everyone is expected to ignore it because > XMAX_IS_INVALID, yet somehow the MULTIXACT bit was also set and the new > code expects to be able to look at the xmax field even though it's > marked as invalid.. XMAX_IS_INVALID was never allowed to be ignored for vacuum AFAICS. So I don't think this is a valid explanation. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers