Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WxRkP-000324-Sp for pgsql-bugs@arkaria.postgresql.org; Thu, 19 Jun 2014 02:06:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WxRkO-0007ei-Np for pgsql-bugs@arkaria.postgresql.org; Thu, 19 Jun 2014 02:06:40 +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 1WxRkM-0007eZ-HB for pgsql-bugs@postgresql.org; Thu, 19 Jun 2014 02:06:38 +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 1WxRkJ-0001Uh-6v for pgsql-bugs@postgresql.org; Thu, 19 Jun 2014 02:06:36 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1WxRkH-0005NQ-2J; Wed, 18 Jun 2014 22:06:33 -0400 Date: Wed, 18 Jun 2014 22:06:33 -0400 From: Bruce Momjian To: Alvaro Herrera Cc: Andres Freund , PostgreSQL Bugs Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts Message-ID: <20140619020633.GA20469@momjian.us> References: <20140530121631.GE25431@alap3.anarazel.de> <20140530132916.GM28490@momjian.us> <20140618225131.GN18688@eldon.alvh.no-ip.org> <20140619015205.GD3806@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140619015205.GD3806@momjian.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 Wed, Jun 18, 2014 at 09:52:05PM -0400, Bruce Momjian wrote: > On Wed, Jun 18, 2014 at 06:51:31PM -0400, Alvaro Herrera wrote: > > > This is a bug in 9.3 pg_upgrade as well? Why has no one reported it > > > before? > > > > I think one reason is that not all upgrades see an issue here; for old > > clusters that haven't gone beyond the 0000 offset file, there is no > > problem. For clusters that have gone beyond 0000 but not by much, the > > file will be deleted during the first truncation. It only becomes a > > problem if the cluster is close enough to 2^31. Another thing to keep > > in consideration is that initdb initializes all databases' datminmxid to > > 1. If the old cluster was past the 2^31 point, it means the datminmxid > > doesn't move from 1 until the actual wraparound. > > OK, so the xid has to be beyond 2^31 during pg_upgrade to trigger a > problem? That might explain the rare reporting of this bug. What would > the test query look like so we can tell people when to remove the '0000' > files? Would we need to see the existence of '0000' and high-numbered > files? How high? What does a 2^31 file look like? Also, what would a legitimate 0000 file at wrap-around time look like? Would there have to be an 'ffff' or 'ffffff' file? -- 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