Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)
От | Robert Haas |
---|---|
Тема | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Дата | |
Msg-id | CA+Tgmob8BR-D6Zhjse3j8GA2-Sv=NhV9pZfj72hm0gDErZ_-mA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Re: BUG #12990: Missing pg_multixact/members files
(appears to have wrapped, then truncated)
Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Список | pgsql-bugs |
On Fri, May 8, 2015 at 9:55 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > 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. Here's a patch that attempts to implement this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-bugs по дате отправления: