From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Usage of epoch in txid_current |
Date: | 2017-12-05 09:19:49 |
Message-ID: | CAPpHfdt=xctQxTEb6rzUar=UWKHWbBOfeY1N0K9YgJzSmKxukw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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...
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-12-05 09:26:03 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Nikhil Sontakke | 2017-12-05 08:00:01 | Re: [HACKERS] logical decoding of two-phase transactions |