Date: Tue, 10 Dec 2013 02:00:54 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Serge Negodyuck <petr@petrovich.kiev.ua>, pgsql-bugs@postgresql.org
Subject: Re: BUG #8673: Could not open file
 "pg_multixact/members/xxxx" on slave during hot_standby
Message-ID: <20131210010054.GE27840@awork2.anarazel.de>
References: <E1Vq1BO-00064N-Qn@wrigleys.postgresql.org>
 <20131209142525.GA1123@awork2.anarazel.de>
 <CABKyZDFWn+ty_m88sq2j5UThowb2Qwd0125BNx_19va2Fn57dQ@mail.gmail.com>
 <20131209150345.GB1123@awork2.anarazel.de>
 <CABKyZDFRtDzcY1=sEznC2ivmcM5p1yPQvC8qLL8XLviNF2kp7A@mail.gmail.com>
 <20131209182701.GD9519@awork2.anarazel.de>
 <20131209190031.GK6777@eldon.alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131209190031.GK6777@eldon.alvh.no-ip.org>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

On 2013-12-09 16:00:32 -0300, Alvaro Herrera wrote:
> As a note, the SlruScanDirectory code has a flaw because it only looks
> at four-digit files; the reason only files up to 0xFFFF are missing and
> not the following ones is because those got ignored.  This needs a fix
> as well.

While I agree it's a bug, I don't think it's relevant for the case at
hand. For offset's there's no following page (or exactly 1, not sure
about the math offhand), and we only use SlruScanDirectory() for
offsets not for members.

> > I've recently remarked that I find it dangerous that we only do
> > anti-wraparound stuff for pg_multixact/offsets, not for /members. So,
> > here we have the proof that that's bad.
> 
> It's hard to see how to add this post-facto, though.  I mean, I am
> thinking we would need some additional pg_control info etc.  We'd better
> figure out a way to add such controls without having to add that.

Couldn't we just get the oldest multi, check where in offsets it points
to, and compare that with nextOffset? That should be doable without
additional data.

> > I think problems should be preventable if you issue a systemwide VACUUM
> > FREEZE, but please let others chime in before you execute it.
> 
> I wouldn't freeze anything just yet, at least until the patch to fix
> multixact freezing is in.

Well, it seems better than getting errors because of multixact members
that are gone.
Maybe PGOPTIONS='-c vacuum_freez_table_age=0 -c vacuum_freeze_min_age=1000000 vacuumdb -a'
 - that ought not to cause problems with current data and should freeze
enough to get rid of problematic multis?

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