Hi, On 2017-12-06 17:39:09 +0530, Amit Kapila wrote: > We are using ShmemVariableCache->nextXid at many places so always > converting/truncating it to 32-bit number before using seems slightly > awkward, so we can think of using a separate nextBigXid 64bit number > as well.
-many It's not actually that many places. And a lot of them would should be updated anyway, to be epoch aware. Let's not add this kind of crummyness to avoid a few truncating casts here and there. > Either way, it is not clear to me how we will keep it > updated after recovery. Right now, the mechanism is quite simple, at > the beginning of a recovery we take the value of nextXid from > checkpoint record and then if any xlog record indicates xid that > follows nextXid, we advance it. Here, the point to note is that we > take the xid from the WAL record (which means that it assumes xids are > non-contiguous or some xids are consumed without being logged) and > increment it. Unless we plan to change something in that logic (like > storing 64-bit xids in WAL records), it is not clear to me how to make > it work. OTOH, recovering value of epoch which increments only at > wraparound seems fairly straightforward as described in my previous > email. I think it should be fairly simple if simply add the 64bit xid to the existing clog extension WAL records. Greetings, Andres Freund