On Thu, Mar 22, 2012 at 5:26 PM, Daniel Farina <dan...@heroku.com> wrote: > Some time ago I reported bug 6291[0], which reported a Xid wraparound, > both as reported in pg_controldata and by txid_current_snapshot. > Unfortunately, nobody could reproduce it. > > Today, the same system of ours just passed the wraparound mark > successfully at this time, incrementing the epoch. However, two > standbys have not done the same: they have wrapped to a low txid. At > this time, pg_controldata does report the correct epoch, as I read it, > unlike the original case.
Hmm. Here we are again, to revive this old thread (whose archives can be seen at http://archives.postgresql.org/pgsql-hackers/2012-03/msg01437.php) So the system *has* wrapped this time -- and so has its standby -- but not to the zero-epoch, but rather the epoch that it was previously in, 2^33 to 2^32. That's not something I've seen before. There was another report of something similar in that thread also. So, that's...different. However, since we've started using txids for some streaming/incremental copying of data roughly a year ago (and thus started be alerted to this problem), two of the three known wraparounds have been eventful, and the third exposed a potentially unrelated bug in the standby whereby epochs were not being loaded. This database is itself descended from from an old timeline on a version of postgres that undoubtably showed this defect. Version: 9.0.6 Ubuntu 10.04 LTS amd64 -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers