| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Timothy Garnett <tgarnett(at)panjiva(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
| Date: | 2015-05-09 01:55:28 |
| Message-ID: | 20150509015528.GQ2523@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-05-09 02:46:24 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
| Previous Message | Thomas Munro | 2015-05-08 23:41:38 | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |