Re: Usage of epoch in txid_current - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Usage of epoch in txid_current
Date
Msg-id CAPpHfdt=xctQxTEb6rzUar=UWKHWbBOfeY1N0K9YgJzSmKxukw@mail.gmail.com
Whole thread Raw
In response to Usage of epoch in txid_current  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Usage of epoch in txid_current
List pgsql-hackers
Hi! On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila 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... Am I missing something which ensures that epoch gets incremented at or > after wraparound? > I've checked the code, and it doesn't look for me that there is something like this. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions