Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>, Simon Riggs <simon.riggs@enterprisedb.com>, Maxim Orlov <orlovmg@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-07T16:14:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add SLRU tests for 64-bit page case

  2. Make use FullTransactionId in 2PC filenames

  3. Use larger segment file names for pg_notify

  4. Index SLRUs by 64-bit integers rather than by 32-bit integers

On 07.01.22 06:18, Fujii Masao wrote:
> On 2022/01/06 19:24, Simon Riggs wrote:
>> On Thu, 30 Dec 2021 at 13:19, Maxim Orlov <orlovmg@gmail.com> wrote:
>>
>>> Your opinions are very much welcome!
>>
>> This is a review of the Int64 options patch,
>> "v6-0001-Add-64-bit-GUCs-for-xids.patch"
> 
> Do we really need to support both int32 and int64 options? Isn't it 
> enough to replace the existing int32 option with int64 one?

I think that would create a lot of problems.  You'd have to change every 
underlying int variable to int64, and then check whether that causes any 
issues where they are used (wrong printf format, assignments, 
overflows), and you'd have to check whether the existing limits are 
still appropriate.  And extensions would be upset.  This would be a big 
mess.

> Or how about 
> using string-type option for very large number like 64-bit XID, like 
> it's done for recovery_target_xid?

Seeing how many variables that contain transaction ID information 
actually exist, I think it could be worth introducing a new category as 
proposed.  Otherwise, you'd have to write a lot of check and assign hooks.

I do wonder whether signed vs. unsigned is handled correctly. 
Transaction IDs are unsigned, but all GUC handling is signed.