Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wd1Tx-0006JQ-QQ for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Apr 2014 18:01:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wd1Tx-0007cP-7P for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Apr 2014 18:01:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wd1Tv-0007cF-TL for pgsql-hackers@postgresql.org; Wed, 23 Apr 2014 18:01:15 +0000 Received: from smtprelay0075.b.hostedemail.com ([64.98.42.75] helo=smtprelay.b.hostedemail.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wd1Tn-0006lA-GD for pgsql-hackers@postgresql.org; Wed, 23 Apr 2014 18:01:15 +0000 Received: from filter.hostedemail.com (b-bigip1 [10.5.19.254]) by smtprelay02.b.hostedemail.com (Postfix) with ESMTP id 2E3B3D39BD; Wed, 23 Apr 2014 18:01:06 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, alvherre@alvh.no-ip.org, :::::, RULES_HIT:41:355:379:599:871:966:967:973:988:989:1260:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1541:1575:1594:1595:1596:1711:1730:1747:1764:1777:1792:2196:2199:2393:2525:2560:2563:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4385:4470:4605:4659:5007:6261:6748:7281:7909:9025:9121:10004:10394:10400:10450:10455:10848:10967:11026:11232:11256:11257:11604:11638:11658:11914:12296:12438:12517:12519:12660:12663:12740:13894:13895:19904:19999, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0 X-HE-Tag: idea24_956c9179761f X-Filterd-Recvd-Size: 3305 Received: from eldon.alvh.no-ip.org (unknown [190.215.45.233]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf02.b.hostedemail.com (Postfix) with ESMTPA; Wed, 23 Apr 2014 18:01:04 +0000 (UTC) Received: by eldon.alvh.no-ip.org (Postfix, from userid 1000) id BCAEC1FCC; Wed, 23 Apr 2014 15:01:02 -0300 (CLST) Date: Wed, 23 Apr 2014 15:01:02 -0300 From: Alvaro Herrera To: Andres Freund Cc: Stephen Frost , pgsql-hackers@postgresql.org Subject: Re: MultiXactId error after upgrade to 9.3.4 Message-ID: <20140423180102.GP25695@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: multipart/mixed; boundary="JWEK1jqKZ6MHAcjA" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140331115713.GA18358@alap3.anarazel.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -1.9 (-) 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 --JWEK1jqKZ6MHAcjA Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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. I think what we should do here is that if we see that XMAX_INVALID is set, we just reset everything to zero without checking the multixact contents. Something like the attached (warning: hand-edited, line numbers might be bogus) I still don't know under what circumstances this situation could arise. This seems most strange to me. I would wonder about this to be just papering over a different bug elsewhere, except that we know this tuple comes from a pg_upgraded table and so I think the only real solution is to cope. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services --JWEK1jqKZ6MHAcjA Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="no-freeze-invalid-multi.patch" diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 9283b70..72602fd 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -5585,7 +5602,12 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid, */ xid = HeapTupleHeaderGetRawXmax(tuple); - if (tuple->t_infomask & HEAP_XMAX_IS_MULTI) + if ((tuple->t_infomask & HEAP_XMAX_IS_MULTI) && + (tuple->t_infomask & HEAP_XMAX_INVALID)) + { + freeze_xmax = true; + } + else if (tuple->t_infomask & HEAP_XMAX_IS_MULTI) { TransactionId newxmax; uint16 flags; --JWEK1jqKZ6MHAcjA 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 --JWEK1jqKZ6MHAcjA--