From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: Sun, 20 Jul 2014 23:32:58 +0200
Message-ID: <20140720213258.GD5974@alap3.anarazel.de> (raw)
In-Reply-To: <15685.1405891368@sss.pgh.pa.us>
References: <20140624201346.GB17110@momjian.us>
<20140627210520.GP7340@eldon.alvh.no-ip.org>
<20140701161419.GA16033@momjian.us>
<20140701190105.GA7340@eldon.alvh.no-ip.org>
<20140701193047.GB16033@momjian.us>
<9879.1405877821@sss.pgh.pa.us>
<20140720200225.GA5974@alap3.anarazel.de>
<13755.1405887378@sss.pgh.pa.us>
<20140720204852.GB5974@alap3.anarazel.de>
<15685.1405891368@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
On 2014-07-20 17:22:48 -0400, Tom Lane wrote:
> 2. However, pg_upgrade also sets datminmxid/relminmxid to equal the old
> cluster's NextMultiXactId. The trouble with this is that it might fool
> (auto)vacuum into never seeing and freezing the pre-upgrade mxids; they're
> in the table but the metadata says not, so we'd not force a full table
> scan to find them.
We effectively can't actually assume those are going to be vacuumed away
anyway. There might have been 2**32 mxids in the older cluster already -
no value of datminmxid/relminmxid can protect us against that.
> 4. The patch Bruce applied to initialize datminmxid/relminmxid to the old
> NextMultiXactId rather than 1 does not fundamentally change anything here.
> It narrows the window in which wraparound can cause problems, but only by
> the distance that "1" is in-the-future at the time of upgrade.
I think it's actually more than that. Consider what happens if
pg_upgrade has used pg_resetxlog to set nextMulti to > 2^31. If
rel/datminmxid are set to 1 regardless vac_update_relstats() and
vac_update_datfrozenxid() won't increase them anymore because of:
/* relminmxid must never go backward, either */
if (MultiXactIdIsValid(minmulti) &&
MultiXactIdPrecedes(pgcform->relminmxid, minmulti))
{
pgcform->relminmxid = minmulti;
dirty = true;
}
And that can actually cause significant problems once 9.3+ creates new
multis because they'll never get vacuumed away but still do get
truncated. If it's an updating multi xmax that can effectively make the
row unreadable - not just block updates.
Greetings,
Andres Freund
--
Andres Freund 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: andres@2ndquadrant.com, tgl@sss.pgh.pa.us, bruce@momjian.us, alvherre@2ndquadrant.com
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
In-Reply-To: <20140720213258.GD5974@alap3.anarazel.de>
* 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