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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com>
Cc: btfujiitkp <btfujiitkp(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Should we add xid_current() or a int8->xid cast?
Date: 2019-11-20 10:51:07
Message-ID: CA+hUKGJFJFjK5OCb4tQ+41g_-1N1-hfp6=TfaMzrt2Vk0r8h9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 20, 2019 at 5:43 PM imai(dot)yoshikazu(at)fujitsu(dot)com
<imai(dot)yoshikazu(at)fujitsu(dot)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...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-11-20 11:36:22 Re: [HACKERS] Block level parallel vacuum
Previous Message Masahiko Sawada 2019-11-20 10:34:07 Re: [HACKERS] Block level parallel vacuum