Re: Could not finish anti-wraparound VACUUM when stop limit is reached

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Could not finish anti-wraparound VACUUM when stop limit is reached
Date: 2014-05-25 15:53:45
Message-ID: 20140525155345.GA18867@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2014-05-25 15:54:06 [9.5] possible fast path for pinning a page multiple times
Previous Message Andres Freund 2014-05-25 15:45:11 Re: pg9.4b1: unhelpful error message when creating a collation