Date: Wed, 18 Dec 2013 20:13:12 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Serge Negodyuck <petr@petrovich.kiev.ua>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@postgresql.org
Subject: Re: BUG #8673: Could not open file
 "pg_multixact/members/xxxx" on slave during hot_standby
Message-ID: <20131218191312.GA26481@alap2.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>
 <20131210010054.GE27840@awork2.anarazel.de>
 <20131210042520.GN6777@eldon.alvh.no-ip.org>
 <CABKyZDEENX2X5HMqNtMB34zBAr2UZxrcs4SbXx169xDRKeZ4DA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CABKyZDEENX2X5HMqNtMB34zBAr2UZxrcs4SbXx169xDRKeZ4DA@mail.gmail.com>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Hi,

On 2013-12-18 16:20:48 +0200, Serge Negodyuck wrote:
> You guys were right. After a week this issue occured again on almost
> all slave servers.

Not surprising.

> My question is are there any quick-and-dirty solution to disable
> pg_multixact deletion? I understand it may lead to waste of space.

Your problem isn't the deletion but that a) multixactid members wrapped
around, partially overwriting old data b) some multixacts contain too
old members (c.f. 9.3.2)

> The only way out was to perform full backup/restore, which did not
> succeed with teh same error (could not access status of transaction
> xxxxxxx)
> A very ugly hack was to copy pg_multixact/members/0000 ->
> pg_multixact/members/[ABCDF]xxx, it helped to do full backup, but not
> sure about consistency of data.

That will likely cause corruption.

I think your best bet is to hack GetMultiXactIdMembers to return -1 for
old multixacts, on the theory that those rows would have been removed by
VACUUM if they had a valid xmax.

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