pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@2ndquadrant.com>
To: Serge Negodyuck <petr@petrovich.kiev.ua>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
Date: Wed, 18 Dec 2013 20:13:12 +0100
Message-ID: <20131218191312.GA26481@alap2.anarazel.de> (raw)
In-Reply-To: <CABKyZDEENX2X5HMqNtMB34zBAr2UZxrcs4SbXx169xDRKeZ4DA@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>

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



view thread (35+ messages)  latest in thread

Message-ID: <20131218191312.GA26481@alap2.anarazel.de>
Permalink:  ../20131218191312.GA26481@alap2.anarazel.de/
Also on:    postgresql.org/message-id/20131218191312.GA26481@alap2.anarazel.de

 · 

reply

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-hackers@postgresql.org
  Cc: andres@2ndquadrant.com, petr@petrovich.kiev.ua, alvherre@2ndquadrant.com, pgsql-bugs@postgresql.org
  Subject: Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
  In-Reply-To: <20131218191312.GA26481@alap2.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