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.
In response to
pgsql-bugs by date
|Next:||From: David Pinheiro||Date: 2011-11-14 16:31:02|
|Subject: BUG #6292: java.sql.PreparedStatement.setNull() throws PSQLException|
|Previous:||From: Robert Haas||Date: 2011-11-14 02:35:58|
|Subject: Re: BUG #4335: Error w/ PostgreSQL & EnterpriseDB Stack Builder|