On Wed, Jun 18, 2014 at 06:51:31PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, May 30, 2014 at 02:16:31PM +0200, Andres Freund wrote:
> > > Hi,
> > >
> > > When upgrading a < 9.3 cluster pg_upgrade doesn't bother to keep the old
> > > multixacts around because they won't be read after the upgrade (and
> > > aren't compatible). It just resets the new cluster's nextMulti to the
> > > old + 1.
> > > Unfortunately that means that there'll be a offsets/0000 file created by
> > > initdb around. Sounds harmless enough, but that'll actually cause
> > > problems if the old cluster had a nextMulti that's bigger than that
> > > page.
>
> I've been playing with this a bit. Here's a patch that just does
> rmtree() of the problematic file during pg_upgrade, as proposed by
> Andres, which solves the problem. Note that this patch removes the 0000
> file in both cases: when upgrading from 9.2, and when upgrading from
> 9.3+. The former case is the bug that Andres reported. In the second
> case, we overwrite the files with the ones from the old cluster; if
> there's a lingering 0000 file in the new cluster, it would cause
> problems as well. (Really, I don't see any reason to think that these
> two cases are any different.)
I wasn't happy with having that delete code added there when we do
directory delete in the function above. I instead broke apart the
delete and copy code and called the delete code where needed, in the
attached patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +