Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date
Msg-id 20140530150006.GP28490@momjian.us
Whole thread Raw
In response to Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-bugs
On Fri, May 30, 2014 at 03:32:44PM +0200, Andres Freund wrote:
> On 2014-05-30 09:29:16 -0400, Bruce Momjian wrote:
> > This is a bug in 9.3 pg_upgrade as well?
>
> Yes.
>
> >  Why has no one reported it before?
>
> My guess is that it wasn't attributed to pg_upgrade in the
> past. Typically the error will only occur a fair amount of time
> later. You'll just see vacuums randomly erroring out with slru.c errors
> about nonexistant files :(.

But how much later?  pg_upgrade is pretty popular now but I am just not
seeing the number of errors as I would expect:

    ERROR: could not access status of transaction 2072053907
    DETAIL: Could not open file "pg_multixact/offsets/7B81": No such file or directory.

I am not saying there is no bug, but from your analysis it would seem to
be 100% of pg_upgrade'ed clusters that use multi-xacts.  Is that true?
If so, it seems we would need to tell everyone to remove the 0000 files
if there are higher numbered ones with numbering gaps.  Is this
something our next minor release should fix in the multi-xacts code?
Fixing pg_upgrade seems like the easy part.

--
  Bruce_ Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

pgsql-bugs by date:

Previous
From: Sandro Santilli
Date:
Subject: Re: uninterruptable loop: concurrent delete in progress within table
Next
From: Andres Freund
Date:
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts