This is the multi-page printable view of this section. .
Customized Options
Dossier URLs remain flat; this category exists only to organize browsing and the sidebar.
1 - custom_variable_classes
Fact — official short description: “Sets the list of known custom variable classes.”
Identity
Type,- Upstream pg_settings type
Context,- Takes effect after configuration reload
Unit,- Raw unit
Range,- Raw limits in the last observed version
Enum values,- — for non-enum types
Category,- Upstream classification
Latest boot value,- not set
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG9.0 (research boundary) |
| Present in | PG9.0–9.1 |
| Removed in | PG9.2 |
| Introduction commit | Not asserted: predates the PG9.0 research boundary |
| Commit date | — |
| Discussion | — |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG9.0–9.1 | — | — | not set |
How it works
PostgreSQL describes custom_variable_classes as follows: “Sets the list of known custom variable classes.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.1; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.
Old releases required extensions and applications to predeclare accepted custom GUC prefixes. PostgreSQL 9.2 removed that registration mechanism; modern servers accept any two-part custom name and preserve an unrecognized placeholder until the defining extension is loaded.
Read it together with shared_preload_libraries, session_preload_libraries, config_file, allow_alter_system. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| OLTP | Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it. |
| OLAP | For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable. |
| Small nodes | Delete the obsolete override after recording why it existed. On a small node, prefer the successor’s default until measurements justify a new value; an unknown startup parameter can otherwise stop the server. |
Pigsty
Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.1; this does not assert current Pigsty support for that historical or beta release.
| Template | Effective value | Versus upstream boot | Source expression |
|---|---|---|---|
| OLTP | Unmodified | — | — |
| OLAP | Unmodified | — | — |
| CRIT | Unmodified | — | — |
| TINY | Unmodified | — | — |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–9.1 unmodified; OLAP: PG9.0–9.1 unmodified; CRIT: PG9.0–9.1 unmodified; TINY: PG9.0–9.1 unmodified. No Pigsty-specific rationale is inferred from an absent override.
Common pitfalls
- Treating the measured boot_val for custom_variable_classes as proof of the effective value on an initialized or managed cluster.
- Applying a change as though it were immediate while pg_settings reports sighup context.
- Changing this setting in isolation without checking the linked limits, observability, and rollback path.
- Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.
Related parameters
shared_preload_libraries · session_preload_libraries · config_file · allow_alter_system