POC: make mxidoff 64 bits

Поиск
Список
Период
Сортировка
От Maxim Orlov
Тема POC: make mxidoff 64 bits
Дата
Msg-id CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com
обсуждение исходный текст
Ответы Re: POC: make mxidoff 64 bits
Re: POC: make mxidoff 64 bits
Список pgsql-hackers
Hi!

I've been trying to introduce 64-bit transaction identifications to Postgres for quite a while [0]. All this implies,
of course, an enormous amount of change that will have to take place in various modules. Consider this, the
patch set become too big to be committed “at once”.

The obvious solutions was to try to split the patch set into smaller ones. But here it comes a new challenge,
not every one of these parts, make Postgres better at the moment. Actually, even switching to a
FullTransactionId in PGPROC will have disadvantage in increasing of WAL size [1].

In fact, I believe, we're dealing with the chicken and the egg problem here. Not able to commit full patch set
since it is too big to handle and not able to commit parts of it, since they make sense all together and do not
help improve Postgres at the moment.

But it's not that bad. Since the commit 4ed8f0913bfdb5f, added in [3], we are capable to use 64 bits to
indexing SLRUs.

PROPOSAL
Make multixact offsets 64 bit.

RATIONALE
It is not very difficult to overflow 32-bit mxidoff. Since, it is created for every unique combination of the
transaction for each tuple, including XIDs and respective flags. And when a transaction is added to a
specific multixact, it is rewritten with a new offset. In other words, it is possible to overflow the offsets of
multixacts without overflowing the multixacts themselves and/or ordinary transactions. I believe, there
was something about in the hackers mail lists, but I could not find links now.

PFA, patch. Here is a WIP version. Upgrade machinery should be added later.

As always, any opinions on a subject a very welcome!


--
Best regards,
Maxim Orlov.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: pg_stat_statements and "IN" conditions
Следующее
От: Tender Wang
Дата:
Сообщение: Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()