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 22:48:52 +0200
Message-ID: <20140720204852.GB5974@alap3.anarazel.de> (raw)
In-Reply-To: <13755.1405887378@sss.pgh.pa.us>
References: <20140620010653.GS18688@eldon.alvh.no-ip.org>
<20140620180725.GD29143@momjian.us>
<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
On 2014-07-20 16:16:18 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-07-20 13:37:01 -0400, Tom Lane wrote:
> >> I started transcribing Bruce's proposed fix procedure at
> >> https://wiki.postgresql.org/wiki/20140702pg_upgrade_fix
> >> into the release notes, but I'm afraid it's all wet.
>
> > I don't understand why we should do anything but remove the 0000 file if
> > it's all zeroes? This seems far too complicated. Beside the fact that I
> > doubt it's actually achieving anything reliably?
>
> This one is not about the extra 0000 file. It's about whether datminmxid
> and relminmxid are wrong. In the previous coding of pg_upgrade, they'd
> have been left at "1" even if that value has wrapped around into the
> future.
Yea, I'm rereading the thread atm. I'd stopped following it after a
while and didn't notice the drift into a second problem.
> Now, if you were lucky, you'd have no bad side-effects even if they had
> wrapped around ...
Hm. If relminmxid = 1 is still in the past everything should be fine,
right? The next vacuum (which will run soon) will just set it anew. But
if not
/* relminmxid must never go backward, either */
if (MultiXactIdIsValid(minmulti) &&
MultiXactIdPrecedes(pgcform->relminmxid, minmulti))
{
pgcform->relminmxid = minmulti;
dirty = true;
}
will prevent it from being changed. Similarly
/* ditto */
if (MultiXactIdPrecedes(dbform->datminmxid, newMinMulti))
{
dbform->datminmxid = newMinMulti;
dirty = true;
}
will prevent datminmxid from becoming sane.
vac_truncate_clog() will be called with ReadNextMultiXactId() - -
autovacuum_multixact_freeze_max_age as the truncation for multis. That
itself would be fine since there won't be any actual multis in that
range. The problem is that we might miss having to do a full table
vacuum because
we check relminmxid to determine that:
scan_all |= MultiXactIdPrecedesOrEquals(onerel->rd_rel->relminmxid,
mxactFullScanLimit);
which then could cause problems in the future.
Imo that means we need to fix this :( for existing clusters.
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: <20140720204852.GB5974@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