Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wy3HL-0006TI-4J for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Jun 2014 18:11:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wy3HK-00073A-GH for pgsql-bugs@arkaria.postgresql.org; Fri, 20 Jun 2014 18:11:10 +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 1Wy3HJ-00070u-JH for pgsql-bugs@postgresql.org; Fri, 20 Jun 2014 18:11:09 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Wy3HG-0003sp-Lq for pgsql-bugs@postgresql.org; Fri, 20 Jun 2014 18:11:07 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Wy3HE-0002Of-Tx; Fri, 20 Jun 2014 14:11:04 -0400 Date: Fri, 20 Jun 2014 14:11:04 -0400 From: Bruce Momjian To: Tom Lane Cc: Alvaro Herrera , Andres Freund , PostgreSQL Bugs Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8519.1403286102@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) 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 On Fri, Jun 20, 2014 at 01:41:42PM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Bruce Momjian wrote: > >> Why would we want this if the system functions fine without those files > >> being created? I don't think we want pg_resetxlog to be doing anything > >> except changing pg_controldata. > > > I don't understand why you say the system functions fine. If you move > > the multixactid with pg_resetxlog to a point which doesn't have the > > necessary file and page, the system will not start. Only pg_upgrade > > knows to create the file appropriately, but normal operation doesn't. > > 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. > > I'm not sure why Alvaro chose to fix this only for pg_multixact, but > fixing that case is better than not fixing anything. 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. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs