Date: Fri, 20 Jun 2014 13:19:15 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>,
 PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around
 multixacts
Message-ID: <20140620171915.GC29143@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140619221240.GC27747@eldon.alvh.no-ip.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

On Thu, Jun 19, 2014 at 06:12:41PM -0400, Alvaro Herrera wrote:
> BTW I hacked up pg_resetxlog a bit to make it generate the necessary
> pg_multixact/offset file when -m is given.  This is not acceptable for
> commit because it duplicates the #defines from pg_multixact.c, but maybe
> we want this functionality enough that we're interested in a more
> complete version of this patch; also it unconditionally writes one zero
> byte to the file, which is of course wrong if the file exists and
> already contains data.

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.

-- 
  Bruce Momjian  <bruce@momjian.us>        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