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.