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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers