From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
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 17:43:04 -0400
Message-ID: <16274.1405892584@sss.pgh.pa.us> (raw)
In-Reply-To: <20140720213258.GD5974@alap3.anarazel.de>
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>
<20140720213258.GD5974@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-07-20 17:22:48 -0400, Tom Lane wrote:
>> 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.
No, I don't think so. Truncation is driven off oldestMultiXid from
pg_control, not from relminmxid. The only thing in-the-future values of
those will do to us is prevent autovacuum from thinking it must do a full
table scan. (In particular, in-the-future values do not cause
oldestMultiXid to get advanced, because we're always looking for the
oldest value not the newest.)
But in any case, we both agree that setting relminmxid to equal nextMulti
is completely unsafe in a 9.3 cluster that's already been up. So the
proposed fix instructions are certainly wrong.
regards, tom lane
--
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: tgl@sss.pgh.pa.us, andres@2ndquadrant.com, bruce@momjian.us, alvherre@2ndquadrant.com
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
In-Reply-To: <16274.1405892584@sss.pgh.pa.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