From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
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: Wed, 2 Jul 2014 11:56:34 -0400
Message-ID: <20140702155634.GD7340@eldon.alvh.no-ip.org> (raw)
In-Reply-To: <20140701014917.GA21190@momjian.us>
References: <20140619020633.GA20469@momjian.us>
<20140619015205.GD3806@momjian.us>
<20140619014034.GC3806@momjian.us>
<20140619220425.GQ18688@eldon.alvh.no-ip.org>
<20140620010653.GS18688@eldon.alvh.no-ip.org>
<20140620180725.GD29143@momjian.us>
<20140624201346.GB17110@momjian.us>
<20140627210520.GP7340@eldon.alvh.no-ip.org>
<20140701014917.GA21190@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Bruce Momjian wrote:
> On Fri, Jun 27, 2014 at 05:05:21PM -0400, Alvaro Herrera wrote:
> > > Do they need to remove the members/0000 file too?
> >
> > No, the members file shouldn't be removed; if they have used multixacts
> > at all since upgrading, the members/0000 file contains the members of
> > the first bunch of multis. Removing it would remove valid data. (Also
> > I still think that removing the members/0000 file that initdb creates is
> > a mistake.)
>
> We never remove offset or members files with user data; we are only
> discussing the removal of empty files created by initdb. Can you
> explain why we would remove the offsets file but retain the members file
> created by initdb when we are _not_ preserving files from the old
> cluster? We are certainly setting the offset and member value from the
> old cluster:
>
> exec_prog(UTILITY_LOG_FILE, NULL, true,
> "\"%s/pg_resetxlog\" -m %u,%u \"%s\"",
> new_cluster.bindir,
> old_cluster.controldata.chkpnt_nxtmulti + 1,
> old_cluster.controldata.chkpnt_nxtmulti,
> new_cluster.pgdata);
>
> How are we not creating a gap in members files by setting the members
> value? Why will that not cause problems?
We're not setting the offset and member value here; we're setting the
"nextMulti" and "oldestMulti" values. Both affect the offsets counter,
not the members counter. The members counter is kept at zero, so the
next multi to be allocated will create members starting from the first
members position in page zero. initdb of the new cluster created the
first members page, which corresponds to the first members value that
will be used.
Note pg_resetxlog --help says:
-m MXID,MXID set next and oldest multitransaction ID
I think you're confusing the fact that we pass two values here (next and
oldest, both apply to offset counters) with offsets vs. members.
To affect the members counter you would use this other pg_resetxlog switch:
-O OFFSET set next multitransaction offset
which, AFAICS, we only use when upgrading from a 9.3+ cluster to a newer
9.3+ cluster (and we also copy the files from old cluster to the new
one).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
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: alvherre@2ndquadrant.com, bruce@momjian.us, andres@2ndquadrant.com
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
In-Reply-To: <20140702155634.GD7340@eldon.alvh.no-ip.org>
* 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