Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
Date
Msg-id 20150509015528.GQ2523@alvh.no-ip.org
Whole thread Raw
In response to Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
List pgsql-bugs
Thomas Munro wrote:

> I think I see why, and I think it's a bug:  if you vacuum freeze all
> your databases, MultiXactState->oldestMultiXactId finishes up equal to
> MultiXactState->nextMXact.

Uhm, that's rather silly.

> But that's not actually a multixact that exists yet, so when when
> DetermineSafeOldestOffset calls find_multixact_start, it reads a
> garbage offset (all zeros in practice since pages start out zeroed)
> and produces a garbage value for offsetStopLimit which might
> incorrectly stop you from creating any more multixacts even though
> member space is entirely empty (but it depends on where your
> nextOffset happens to be at the time).

Right.

> I think the fix is something like "if nextMXact == oldestMultiXactId,
> then there are no active multixacts, so the offsetStopLimit should be
> set to nextOffset - (a segment's worth)".

Makes sense.

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

pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
Next
From: Robert Haas
Date:
Subject: Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)