From: Andres Freund <andres@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: Fri, 30 May 2014 17:13:17 +0200
Message-ID: <20140530151317.GB1220@awork2.anarazel.de> (raw)
In-Reply-To: <20140530150006.GP28490@momjian.us>
References: <20140530121631.GE25431@alap3.anarazel.de>
<20140530132916.GM28490@momjian.us>
<20140530133244.GG25431@alap3.anarazel.de>
<20140530150006.GP28490@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
On 2014-05-30 11:00:06 -0400, Bruce Momjian wrote:
> 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.
It'd need to be clusters that used more multixacts than fit onto two
slru offsets/ segments in < 9.2. Otherwise things will probably just
continue to work because there's no hole.
Also the new cluster needs to have used more than
vacuum_multixact_freeze_min_age multis after the upgrade to make the
problem visible. I think.
> If so, it seems we would need to tell everyone to remove the 0000 files
> if there are higher numbered ones with numbering gaps.
The problem is that it's not actually that easy to define whether
there's a gap - after a multixact id wraparound the 0000 file might
exist again. So I'd rather not give a simple instruction that might
delete critical data.
> Is this something our next minor release should fix in the multi-xacts
> code?
I wondered whether we could detect that case and deal with it
transparently, but haven't come up with something smart. Alvaro?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
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: 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: <20140530151317.GB1220@awork2.anarazel.de>
* 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