Re: Should we add xid_current() or a int8->xid cast? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Should we add xid_current() or a int8->xid cast?
Date
Msg-id CA+hUKGJFJFjK5OCb4tQ+41g_-1N1-hfp6=TfaMzrt2Vk0r8h9Q@mail.gmail.com
Whole thread Raw
In response to RE: Should we add xid_current() or a int8->xid cast?  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
List pgsql-hackers
On Wed, Nov 20, 2019 at 5:43 PM imai.yoshikazu@fujitsu.com
<imai.yoshikazu@fujitsu.com> wrote:
> Is there any agreement we can throw the wraparound problem away if we adopt
> FullTransactionId?

Here is one argument for why 64 bits ought to be enough: we use 64 bit
LSNs for the WAL, and it usually takes more than one byte of WAL to
consume a transaction.  If you write about 500MB of WAL per second,
your system will break in about a thousand years due to LSN
wraparound, that is, assuming the earth hasn't been destroyed to make
way for a hyperspace bypass, but either way you will probably still
have some spare full transaction IDs.

That's fun to think about, but unfortunately it's not easy to figure
out how to retrofit FullTransactionId into enough places to make
wraparounds go away in the traditional heap.  It's a goal of at least
a couple of ongoing new AM projects to not have that problem, and I
figured it was a good idea to lay down very basic facilities for that,
trivial as they might be, and see where else they can be useful...



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum