-
Notifications
You must be signed in to change notification settings - Fork 2
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/6021~1
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/6021
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 5 commits
- 14 files changed
- 2 contributors
Commits on Sep 14, 2025
-
There is a tendency for boolean reloptions in PostgreSQL code, one with "on" and "off" values, to be replaced with options with "on", "off", "[use_global_settings]" behaviour. For `vacuum_index_cleanup" and gist's `buffering` reloption such behavior have been implemented as enum-tyoe option. For vacuum_truncate this behaviour have been umplemented by adding additional `is_set` flag to `bytea` representation of the reloptions. Both solutions looks like workaround hacks to implement option with three available states. This patch introduce "ternary" reloption type, that behave like bool option, but also has an additional "unset" state. This state may be reachable only by not setting or RESETting an option, like in `vacuum_truncate` option, or it may have some text alias that allow user to explicitly set it, like "auto" in `vacuum_index_cleanup` or gist's `buffering` `vacuum_truncate`, `vacuum_index_cleanup` and gist's `buffering` reloptions are reimplemented as ternary reloptions without significant behaviour changes.
Configuration menu - View commit details
-
Copy full SHA for a802c9a - Browse repository at this point
Copy the full SHA a802c9aView commit details -
Introduce ternary reloption as a replacement for current `vacuum_truncate` implementation. Remove `vacuum_truncate_set` additional flag and using `TERNARY_UNSET` value instead.
Configuration menu - View commit details
-
Copy full SHA for 3ca5e84 - Browse repository at this point
Copy the full SHA 3ca5e84View commit details -
Add alias to be used as "unset" state.
Add `unset_alias` string parameter to ternary reloption definition. This will allow user explicitly switch ternary option to "unset" state. Use this feature to implement `vacuum_index_cleanup` and gist's `buffering` reloptions as ternary reloptions
Configuration menu - View commit details
-
Copy full SHA for acea5f9 - Browse repository at this point
Copy the full SHA acea5f9View commit details -
Add more tests for ternary reloptions in dummy_index_am module
Configuration menu - View commit details
-
Copy full SHA for 6cf3365 - Browse repository at this point
Copy the full SHA 6cf3365View commit details -
[CF 6021] trenary reloption type
This branch was automatically generated by a robot using patches from an email thread registered at: https://commitfest.postgresql.org/patch/6021 The branch will be overwritten each time a new patch version is posted to the thread, and also periodically to check for bitrot caused by changes on the master branch. Patch(es): https://www.postgresql.org/message-id/4047390.3Lj2Plt8kZ@thinkpad-pgpro Author(s): Nikolay Shaplov
Commitfest Bot committedSep 14, 2025 Configuration menu - View commit details
-
Copy full SHA for d158b80 - Browse repository at this point
Copy the full SHA d158b80View commit details
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff cf/6021~1...cf/6021