Bartosz Nowak <grubby@go2.pl> writes:
> By the way: isn't that situation a bug in PG? What about a situation
> when this row was obsoleted just before XID counter wrap around and
> there is no way to do vacuum between those facts? The same situation
> would appear.
No, because XID space is circular: you always have exactly 2 billion
transactions before any newly-created row wraps around. (I strongly
suggest you read the manual page I pointed you to.) The bug is that
PG didn't force you to vacuum the table within that time. 8.1 will have
code that warns increasingly stridently and eventually shuts down the
server before wraparound can occur...
> Why should i note the current trans. counter?
See below. Also, if it's not something a bit past 2 billion then this
whole theory is wrong and you don't want to proceed.
> And shouldn't i set XID counter to the max possible value (2^32 = over 4 billion) to avoid some transactions to be
seenas "in the future" ?
No. The VACUUM FREEZE will replace every XID in the "immediate past" 2
billion transactions with FrozenXid, which will make that stuff safe
against backing up the XID counter, and then you want to back up so that
the oldest transactions are seen as "in the past" again. You need to
use a starting XID enough less than 2 billion that you have time to
validate and dump the data before those oldest transactions go out of
range again ... but not more than 2 billion less than where it is when
you shut down, else you will have some unfrozen rows "in the future".
At least that's my theory about how to get out of this. Like I said,
it's untried.
regards, tom lane