Re: Add 64-bit XIDs into PostgreSQL 15 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Add 64-bit XIDs into PostgreSQL 15
Date
Msg-id 9f4d7bdf-633f-2cca-7a77-597fb9b80cb2@oss.nttdata.com
Whole thread Raw
In response to Add 64-bit XIDs into PostgreSQL 15  (Maxim Orlov <orlovmg@gmail.com>)
Responses Re: Add 64-bit XIDs into PostgreSQL 15
Re: Add 64-bit XIDs into PostgreSQL 15
List 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 by date:

Previous
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Delay the variable initialization in get_rel_sync_entry