Re: Usage of epoch in txid_current
От | Andres Freund |
---|---|
Тема | Re: Usage of epoch in txid_current |
Дата | |
Msg-id | 20171206175653.6vo662it7pxgr6j3@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Usage of epoch in txid_current (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Usage of epoch in txid_current
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: