Re: BUG #6291: Xid epoch is not updated properly

On Sun, Nov 13, 2011 at 3:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Daniel Farina" <daniel(at)heroku(dot)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