Date: Mon, 31 Mar 2014 09:19:12 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>, pgsql-hackers@postgresql.org
Subject: Re: MultiXactId error after upgrade to 9.3.4
Message-ID: <20140331121912.GU9567@eldon.alvh.no-ip.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20140331115713.GA18358@alap3.anarazel.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund wrote:
> On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > My conclusion here is that some part of the code is failing to examine
> > XMAX_INVALID before looking at the value stored in xmax itself.  There
> > ought to be a short-circuit.  Fortunately, this bug should be pretty
> > harmless.
> > 
> > .. and after looking, I'm fairly sure the bug is in
> > heap_tuple_needs_freeze.
> 
> heap_tuple_needs_freeze() isn't *allowed* to look at
> XMAX_INVALID. Otherwise it could miss freezing something still visible
> on a standby or after an eventual crash.

Ah, you're right.  It even says so on the comment at the top (no
caffeine yet.)  But what it's doing is still buggy, per this report, so
we need to do *something* ...

-- 
Álvaro Herrera                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