On Tue, Dec 5, 2017 at 2:49 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> Currently, txid_current and friends export a 64-bit format of
>> transaction id that is extended with an “epoch” counter so that it
>> will not wrap around during the life of an installation. The epoch
>> value it uses is based on the epoch that is maintained by checkpoint
>> (aka only checkpoint increments it).
>>
>> Now if epoch changes multiple times between two checkpoints
>> (practically the chances of this are bleak, but there is a theoretical
>> possibility), then won't the computation of xids will go wrong?
>> Basically, it can give the same value of txid after wraparound if the
>> checkpoint doesn't occur between the two calls to txid_current.
>
>
> AFAICS, yes, if epoch changes multiple times between two checkpoints, then
> computation will go wrong. And it doesn't look like purely theoretical
> possibility for me, because I think I know couple of instances of the edge
> of this...
>
Okay, it is quite strange that we haven't discovered this problem till
now. I think we should do something to fix it. One idea is that we
track epoch change in shared memory (probably in the same data
structure (VariableCacheData) where we track nextXid). We need to
increment it when the xid wraparound during xid allocation (in
GetNewTransactionId). Also, we need to make it persistent as which
means we need to log it in checkpoint xlog record and we need to write
a separate xlog record for the epoch change.
Thoughts?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
