Re: MultiXact member wraparound protections are disabled

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "AnandKumar, Karthik" <Karthik(dot)AnandKumar(at)classmates(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: MultiXact member wraparound protections are disabled
Date: 2016-10-13 15:35:20
Message-ID: 20161013153520.4ztsxin56ek3qijb@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

AnandKumar, Karthik wrote:
> Thanks. We started seeing this error right after a SAN FC re-cable effort - so yes, that would make sense.
> We’ll do a little more digging to see if the 0000 could have gotten removed.
> If that’s an older file that we have in our filesystem backups, is it safe to restore from there?

Sure, the files are immutable after they are completed. I worry that if
the system removed it automatically, it would just remove it again,
though. Shouldn't happen on 9.4.5, but it seems just too much of a
coincidence that that file was removed.

Changes such as FC recabling should not cause anything like this. I
mean, why a pg_multixact file and not a table data file? Very fishy.

I'd advise to verify your older logs at the time of restarts whether the
"multixact protections are enabled" message has ever appeared, or it has
always been "protections are disabled". Maybe you've had the problem
for ages and just never noticed ...

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Robinson 2016-10-13 15:49:20 "The index is not optimal" GiST warnings
Previous Message Andreas Joseph Krogh 2016-10-13 14:35:35 Re: pg_upgrade not able to cope with pg_largeobject being in a different tablespace