Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X90Gq-0003GS-6E for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:11:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X90Gp-0005fR-8F for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:11:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X90Go-0005fK-9d for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:11:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X90Gk-0005JW-Uw for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:11:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s6KNBejS018852; Sun, 20 Jul 2014 19:11:40 -0400 From: Tom Lane To: Andres Freund cc: Bruce Momjian , Alvaro Herrera , PostgreSQL Bugs Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts In-reply-to: <18673.1405897470@sss.pgh.pa.us> References: <20140720200225.GA5974@alap3.anarazel.de> <13755.1405887378@sss.pgh.pa.us> <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> Comments: In-reply-to Tom Lane message dated "Sun, 20 Jul 2014 19:04:30 -0400" Date: Sun, 20 Jul 2014 19:11:40 -0400 Message-ID: <18851.1405897900@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) 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 I 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). Oh, wait, I see what you're on about: that cutoff doesn't constrain the global value computed by vac_truncate_clog. Hmm. I wonder whether we should change vac_update_relstats so that it only applies the "relminxid mustn't go backwards" rule as long as relminxid is sane, ie, not in the future. If it is in the future, forcibly update it to the cutoff we actually used. Likewise for relminmxid. And I guess we'd need a similar rule for updating datmin(m)xid. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs