Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X90HH-0003HS-M8 for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:12:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X90HH-00065u-4z for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:12:23 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X90HF-00061K-6D for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:12:21 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X90HA-0000WO-9x for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:12:19 +0000 Received: from intern.anarazel.de (p5DDC4963.dip0.t-ipconnect.de [93.220.73.99]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id D5204500001; Mon, 21 Jul 2014 01:12:14 +0200 (CEST) Date: Mon, 21 Jul 2014 01:12:14 +0200 From: Andres Freund To: Tom Lane Cc: Bruce Momjian , Alvaro Herrera , PostgreSQL Bugs Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts Message-ID: <20140720231214.GH5974@alap3.anarazel.de> References: <20140720204852.GB5974@alap3.anarazel.de> <15685.1405891368@sss.pgh.pa.us> <20140720213258.GD5974@alap3.anarazel.de> <16274.1405892584@sss.pgh.pa.us> <20140720220253.GE5974@alap3.anarazel.de> <17255.1405894611@sss.pgh.pa.us> <20140720223010.GF5974@alap3.anarazel.de> <17935.1405895946@sss.pgh.pa.us> <20140720225653.GG5974@alap3.anarazel.de> <18673.1405897470@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18673.1405897470@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org On 2014-07-20 19:04:30 -0400, Tom Lane wrote: > Andres Freund writes: > > If any *single* full table vacuum after that calls > > vac_update_datfrozenxid() which just needs its datfrozenxid advance by > > one we're in trouble: vac_truncate_clog() will be called with minMulti = > > GetOldestMultiXactId(). > > Uh, no, the cutoff is GetOldestMultiXactId minus > vacuum_multixact_freeze_min_age (or the autovac equivalent). > See vacuum_set_xid_limits. Unfortunately not :(. The stuff computed in vacuum_set_xid_limits isn't used for truncation - which normally is sane because another database might be further behind. void vac_update_datfrozenxid(void) { ... MultiXactId newMinMulti; ... /* * Similarly, initialize the MultiXact "min" with the value that would be * used on pg_class for new tables. See AddNewRelationTuple(). */ newMinMulti = GetOldestMultiXactId(); ... while ((classTup = systable_getnext(scan)) != NULL) { ... if (MultiXactIdPrecedes(classForm->relminmxid, newMinMulti)) newMinMulti = classForm->relminmxid; } ... if (dirty || ForceTransactionIdLimitUpdate()) vac_truncate_clog(newFrozenXid, newMinMulti); } But even if it were, I don't really see how that changes anything? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs