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: Wed, 2 Jul 2014 13:11:51 -0400
Message-ID: <20140702171151.GA20463@momjian.us> (raw)
In-Reply-To: <20140702155634.GD7340@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>
<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>
<20140702155634.GD7340@eldon.alvh.no-ip.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
On Wed, Jul 2, 2014 at 11:56:34AM -0400, Alvaro Herrera wrote:
> > 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).
OK, thanks for the analysis. Attached patch applied back through 9.3.
--
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-bugsAttachments:pg_upgrade.diff (text/x-diff, 1.0K) downloaddiff --git a/contrib/pg_upgrade/pg_upgrade.c b/contrib/pg_upgrade/pg_upgrade.cnew file mode 100644index b32d81e..5e715fc
*** a/contrib/pg_upgrade/pg_upgrade.c
--- b/contrib/pg_upgrade/pg_upgrade.c
*************** copy_clog_xlog_xid(void)
*** 451,461 ****
else if (new_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
{
/*
! * Remove files created by initdb that no longer match the
! * new multi-xid value.
*/
remove_new_subdir("pg_multixact/offsets", false);
- remove_new_subdir("pg_multixact/members", false);
prep_status("Setting oldest multixact ID on new cluster");
--- 451,461 ----
else if (new_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
{
/*
! * Remove offsets/0000 file created by initdb that no longer matches
! * the new multi-xid value. "members" starts at zero so no need to
! * remove it.
*/
remove_new_subdir("pg_multixact/offsets", false);
prep_status("Setting oldest multixact ID on new cluster");
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: <20140702171151.GA20463@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