Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: 2014-05-30 15:00:06
Message-ID: 20140530150006.GP28490@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2014-05-30 15:13:17 Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Previous Message Sandro Santilli 2014-05-30 14:59:10 Re: uninterruptable loop: concurrent delete in progress within table