From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: Fri, 20 Jun 2014 14:09:18 -0400
Message-ID: <20140620180918.GE29143@momjian.us> (raw)
In-Reply-To: <20140620173351.GV18688@eldon.alvh.no-ip.org>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
On Fri, Jun 20, 2014 at 01:33:52PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > 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.
>
> 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.
True, but who would change the multi-xact except pg_upgrade, and would
you want pg_resetxlog to be changing other files in the file system,
perhaps as part of some disaster recovery operation?
The larger question is whether the backend code should more cleanly
handle such cases.
--
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: bruce@momjian.us, alvherre@2ndquadrant.com, andres@2ndquadrant.com
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
In-Reply-To: <20140620180918.GE29143@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox