Hi, Alexander! > Thank you for your work on this subject.
Thanks for your feedback.
> It doesn't look like these *_age GUCs could benefit from being 64-bit,
> before 64-bit transaction ids get in. However, I think there are some
> better candidates.
>
> autovacuum_vacuum_threshold
> autovacuum_vacuum_insert_threshold
> autovacuum_analyze_threshold
>
> This GUCs specify number of tuples before vacuum/analyze. That could
> be more than 2^31. With large tables of small tuples, I can't even
> say this is always impractical to have values greater than 2^31.
Sounds good to me. Fixed.
> > Secondly, DefineCustomInt64Variable() is not test-covered. Turned out
> > it was not even defined (although declared) in the original patch.
> > This was fixed in the attached version. Maybe one of the test modules
> > could use it even if it makes little sense for this particular module?
> > For instance, test/modules/worker_spi/ could use it for
> > worker_spi.naptime.
>
> I don't think there are good candidates among existing extension GUCs.
> I think we could add something for pure testing purposes somewhere in
> src/test/modules.
I found a great candidate in src/test/modules/delay_execution:
```
DefineCustomIntVariable("delay_execution.post_planning_lock_id",
"Sets the advisory lock ID to be
locked/unlocked after planning.",
```
Advisory lock IDs are bigints [1]. I modified the module to use Int64's.
I guess it may also answer Nathan's question.
> > Last but not least, large values like 12345678912345 could be
> > difficult to read. Perhaps we should also support 12_345_678_912_345
> > syntax? This is not implemented in the attached patch and arguably
> > could be discussed separately when and if we merge it.
>
> I also think we're good with 12345678912345 so far.
Fair enough.
PFA the updated patch.
[1]:
https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS
--
Best regards,
Aleksander Alekseev
v2-0001-Support-64-bit-integer-GUCs.patch
Description: Binary data
