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 16:16:18 -0400
Message-ID: <13755.1405887378@sss.pgh.pa.us> (raw)
In-Reply-To: <20140720200225.GA5974@alap3.anarazel.de>
References: <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>
<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
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.
Now, if you were lucky, you'd have no bad side-effects even if they had
wrapped around ... but if you're not so lucky, you'd get failures due to
accesses to nonexistent pg_multixact files, after vacuum has truncated
pg_multixact in the mistaken impression that there are no remaining
references to old mxids.
The solution I just proposed of forcing the minmxid values down to
"now - 2E9" is not that great btw; I think it will result in autovacuum
deciding it has to scan everything in sight, which is the sort of
intensive operation that pg_upgrade was intended to avoid. I'm not sure
we have any alternatives though.
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: <13755.1405887378@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