Re: Usage of epoch in txid_current

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

In response to

Responses

Browse pgsql-hackers by date

  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