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 по дате отправления: