From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
cc: Bruce Momjian <bruce@momjian.us>,
 Alvaro Herrera <alvherre@2ndquadrant.com>,
 PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
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>
Comments: In-reply-to Andres Freund <andres@2ndquadrant.com>
 message dated "Sun, 20 Jul 2014 22:02:25 +0200"
Date: Sun, 20 Jul 2014 16:16:18 -0400
Message-ID: <13755.1405887378@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

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