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

Reply via email to