On Sun, Nov 13, 2011 at 3:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Daniel Farina" <dan...@heroku.com> writes: >> We have on hand a database that makes heavy use of the txid_snapshot family >> of functions, and recently it just passed its 4^32 transaction mark. >> Unfortunately, upon wraparound the xid epoch appears to not have been >> incremented, remaining at 0. > > I failed to reproduce this here, and a look at the code responsible for > xid epoch maintenance reveals no obvious way that it could have been > bypassed. So there's some fairly critical piece of context that you're > not telling us ...
Hmm, the database has nothing particularly special about it; I also reviewed the epoch code and don't see any simple oversight. On the other hand, I should have the WAL that plays past the epoch wrap, so I can instrument some telltale bit of code; if you have any special suggestion about the diagnostics I'd like to hear them. Also, do you see anything strange about the pg_controldata as-is? I'm looking at in particular the greater-than 2**32 oldestXID seems in line with expectation, yet calling txid_current et-al exposes a number in the hundreds of thousands, as reflected in nextXID. -- fdr -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
