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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Should we add xid_current() or a int8->xid cast?
Дата
Msg-id CA+hUKGJFJFjK5OCb4tQ+41g_-1N1-hfp6=TfaMzrt2Vk0r8h9Q@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Should we add xid_current() or a int8->xid cast?  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum