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
