Bartosz Nowak <grubby@xxxxxx> 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 seen as "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
