On Sun, Nov 13, 2011 at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Daniel Farina" <daniel@heroku.com> writes:
>> We have on hand a database that makes heavy use of the txid_snapshot fam=
ily
>> 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. =A0So 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.
--=20
fdr