Re: Add 64-bit XIDs into PostgreSQL 15

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Add 64-bit XIDs into PostgreSQL 15
Дата
Msg-id 9f4d7bdf-633f-2cca-7a77-597fb9b80cb2@oss.nttdata.com
обсуждение исходный текст
Ответ на Add 64-bit XIDs into PostgreSQL 15  (Maxim Orlov <orlovmg@gmail.com>)
Ответы Re: Add 64-bit XIDs into PostgreSQL 15  (Peter Geoghegan <pg@bowt.ie>)
Re: Add 64-bit XIDs into PostgreSQL 15  (Maxim Orlov <orlovmg@gmail.com>)
Список pgsql-hackers

On 2021/12/30 21:15, Maxim Orlov wrote:
> Hi, hackers!
> 
> Long time wraparound was a really big pain for highly loaded systems. One source of performance degradation is the
needto vacuum before every wraparound.
 
> And there were several proposals to make XIDs 64-bit like [1], [2], [3] and [4] to name a few.
> 
> The approach [2] seems to have stalled on CF since 2018. But meanwhile it was successfully being used in our Postgres
Profork all time since then. We have hundreds of customers using 64-bit XIDs. Dozens of instances are under load that
requirewraparound each 1-5 days with 32-bit XIDs.
 
> It really helps the customers with a huge transaction load that in the case of 32-bit XIDs could experience
wraparoundsevery day. So I'd like to propose this approach modification to CF.
 
> 
> PFA updated working patch v6 for PG15 development cycle.
> It is based on a patch by Alexander Korotkov version 5 [5] with a few fixes, refactoring and was rebased to PG15.

Thanks a lot! I'm really happy to see this proposal again!!

Is there any documentation or README explaining this whole 64-bit XID mechanism?

Could you tell me what happens if new tuple with XID larger than xid_base + 0xFFFFFFFF is inserted into the page? Such
newtuple is not allowed to be inserted into that page? Or xid_base and xids of all existing tuples in the page are
increased?Also what happens if one of those xids (of existing tuples) cannot be changed because the tuple still can be
seenby very-long-running transaction?
 

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Delay the variable initialization in get_rel_sync_entry