Re: Could not finish anti-wraparound VACUUM when stop limit is reached
От | Andres Freund |
---|---|
Тема | Re: Could not finish anti-wraparound VACUUM when stop limit is reached |
Дата | |
Msg-id | 20140525155345.GA18867@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Could not finish anti-wraparound VACUUM when stop limit is reached (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Could not finish anti-wraparound VACUUM when stop limit
is reached
|
Список | pgsql-hackers |
On 2014-05-25 11:40:09 -0400, Heikki Linnakangas wrote: > So, vac_truncate_clog() tries to get a new transaction ID, which fails > because we've already reached the stop-limit. vac_truncate_clog() doesn't > really need a new XID to be assigned, though, it only uses it to compare > against datfrozenxid to see if wrap-around has already happened, so it could > use ReadNewTransactionId() instead. Right. But IIRC we need one in the vicinity anyway to write new pg_database et al rows? > Jeff's database seems to have wrapped around already, because after fixing > the above, I get this: > > jjanes=# vacuum; > WARNING: some databases have not been vacuumed in over 2 billion > transactions > DETAIL: You might have already suffered transaction-wraparound data loss. > VACUUM > > We do not truncate clog when wraparound has already happened, so we never > get past that point. Jeff advanced XID counter aggressively with some custom > C code, so hitting the actual wrap-around is a case of "don't do that". > Still, the case is quite peculiar: pg_controldata says that nextXid is > 4/1593661139. The oldest datfrozenxid is equal to that, 1593661139. So ISTM > he managed to not just wrap around, but execute 2 billion more transactions > after the wraparound and reach datfrozenxid again. I'm not sure how that > happened. I think that may be explained by Jeff's changes to varsup.c to use up xids more rapidly. If JJ_xid is = 1000000 it'll possibly jump right over xidStopLimit. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: