Re: BUG #6291: Xid epoch is not updated properly
От | Daniel Farina |
---|---|
Тема | Re: BUG #6291: Xid epoch is not updated properly |
Дата | |
Msg-id | CAAZKuFb3FaO=emaz6OGb0_32bdzzvb7SkKEJF4jxN_f-Ft7+5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6291: Xid epoch is not updated properly (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: