Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X90fg-0004c4-Cy for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:37:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X90ff-0003DM-PG for pgsql-bugs@arkaria.postgresql.org; Sun, 20 Jul 2014 23:37:35 +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 1X90fe-0003DF-Rz for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:37:34 +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 1X90fV-0005lH-Rj for pgsql-bugs@postgresql.org; Sun, 20 Jul 2014 23:37:33 +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 s6KNbFWp019459; Sun, 20 Jul 2014 19:37:15 -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: <20140720233125.GI5974@alap3.anarazel.de> References: <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> <18851.1405897900@sss.pgh.pa.us> <20140720233125.GI5974@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Mon, 21 Jul 2014 01:31:25 +0200" Date: Sun, 20 Jul 2014 19:37:15 -0400 Message-ID: <19458.1405899435@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 Andres Freund writes: > On 2014-07-20 19:11:40 -0400, Tom Lane wrote: >> 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. > I'm wondering the same. How would we do that from a concurreny POV for > the pg_database rows? I think we could just accept the race condition > that two xacts move dbform->datminmxid backwards to different values > since both have to be 'somewhat' correct? Seems no worse than it is today. Is it even possible for two xacts to be trying to update that at the same time? > I think this is out of the remit for 9.3.5. At least I don't have the > mental capacity to do this properly till tomorrow afternoon. Doesn't sound that hard to me (and I'm still reasonably awake, which I bet you're not). Will take a look. 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