Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wy3Us-0006pm-Go for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Jun 2014 18:25:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wy3Ur-0000ST-Ki for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Jun 2014 18:25:09 +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 1Wy3Uq-0000SJ-Vk for pgsql-bugs@postgresql.org; Fri, 20 Jun 2014 18:25:09 +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 1Wy3Un-0005XR-So for pgsql-bugs@postgresql.org; Fri, 20 Jun 2014 18:25:08 +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 s5KIOtp4009691; Fri, 20 Jun 2014 14:24:55 -0400 From: Tom Lane To: Bruce Momjian cc: Alvaro Herrera , Andres Freund , PostgreSQL Bugs Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts In-reply-to: <20140620181104.GF29143@momjian.us> References: <20140619020633.GA20469@momjian.us> <20140619015205.GD3806@momjian.us> <20140619014034.GC3806@momjian.us> <20140619220425.GQ18688@eldon.alvh.no-ip.org> <20140619221240.GC27747@eldon.alvh.no-ip.org> <20140620171915.GC29143@momjian.us> <20140620173351.GV18688@eldon.alvh.no-ip.org> <8519.1403286102@sss.pgh.pa.us> <20140620181104.GF29143@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Fri, 20 Jun 2014 14:11:04 -0400" Date: Fri, 20 Jun 2014 14:24:55 -0400 Message-ID: <9690.1403288695@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 Bruce Momjian writes: > On Fri, Jun 20, 2014 at 01:41:42PM -0400, Tom Lane wrote: >> Yeah. In my mind, at least, there's been a TODO for some time for >> pg_resetxlog to make sure that pg_clog and the other SLRU-like files >> get populated appropriately when you tell it to change those counters. >> You have to have a segment file at the right place or startup fails. > Well, if we are going to do this, we had better do all cases or the > behavior will be quite surprising, and when doing disaster recovery, > surprises are not good. I am a little worried that removing files as > part of pg_resetxlog might cause data to be lost as users try to figure > things out. Huh? The basic charter of pg_resetxlog is to throw away files, ie, all of your WAL. But in this case what we're talking about is a secondary function, namely the ability to move the XID, MXID, etc counter values. Up to now, if you did that, it was on your head to manually create appropriate SLRU segment files. It's certainly less error-prone, not more so, if the code were to take care of that for you. 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