Version and Platform Compatibility

• 1: allow_alter_system
• 2: array_nulls
• 3: backslash_quote
• 4: default_with_oids
• 5: escape_string_warning
• 6: lo_compat_privileges
• 7: operator_precedence_warning
• 8: quote_all_identifiers
• 9: sql_inheritance
• 10: standard_conforming_strings
• 11: synchronize_seqscans
• 12: transform_null_equals

1 - allow_alter_system

Identity

Lifecycle

Default history

How it works

Allows running the ALTER SYSTEM command. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

When off, PostgreSQL rejects ALTER SYSTEM before it can rewrite postgresql.auto.conf. The switch neither erases existing auto.conf entries nor prevents an operating-system administrator from editing configuration files, so it is an SQL administration boundary rather than a filesystem security boundary.

Monitor and change allow_alter_system together with config_file, data_directory, hba_file. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

config_file · data_directory · hba_file · ident_file · external_pid_file · transform_null_equals

References

• PostgreSQL 19 Beta 3 — allow_alter_system
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - array_nulls

Identity

Lifecycle

Default history

How it works

Enables input of NULL elements in arrays. It can be changed at session scope, so different sessions may observe different behavior.

With the normal on value, an unquoted NULL token in an array input denotes a SQL null element; quoting it denotes the text ‘NULL’. The off value restores pre-8.2 input behavior and exists only for migration of legacy clients.

Monitor and change array_nulls together with backslash_quote, escape_string_warning, standard_conforming_strings. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

backslash_quote · escape_string_warning · standard_conforming_strings · transform_null_equals · quote_all_identifiers · default_with_oids

References

• PostgreSQL 19 Beta 3 — array_nulls
• PostgreSQL 19 release notes
• Machine-readable GUC export

3 - backslash_quote

Identity

Lifecycle

Default history

How it works

Sets whether “'” is allowed in string literals. It can be changed at session scope, so different sessions may observe different behavior.

The safe_encoding mode accepts ' only when the client encoding cannot contain a backslash byte inside a multibyte character. This defense belongs to old string-literal syntax; E’…’ is the explicit escape-string form and standard_conforming_strings governs ordinary strings.

Monitor and change backslash_quote together with array_nulls, escape_string_warning, standard_conforming_strings. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

array_nulls · escape_string_warning · standard_conforming_strings · transform_null_equals · quote_all_identifiers · default_with_oids

References

• PostgreSQL 19 Beta 3 — backslash_quote
• PostgreSQL 19 release notes
• Machine-readable GUC export

4 - default_with_oids

Identity

Lifecycle

Default history

How it works

Create new tables with OIDs by default. The parameter still exists in PG11 and is no longer recognized from PG12. PostgreSQL 12 removed user-table OIDs; use an identity column, sequence, or another explicit key instead.

While present, this changed CREATE TABLE without an explicit WITH/WITHOUT OIDS clause. Table OIDs were neither a durable application key nor guaranteed unique, and the feature disappeared with user-table OIDs in PostgreSQL 12.

Before upgrading, inspect lo_compat_privileges, operator_precedence_warning, synchronize_seqscans, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG12 or later.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG11; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Continuing to emit unknown parameter default_with_oids on PG12+.
• Deleting only the setting name without migrating dependent application behavior.
• Assuming the historical default equals the replacement mechanism’s default.
• Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Related parameters

lo_compat_privileges · operator_precedence_warning · synchronize_seqscans · standard_conforming_strings · array_nulls · backslash_quote

References

• PostgreSQL 11 — default_with_oids
• Machine-readable GUC export

5 - escape_string_warning

Identity

Lifecycle

Default history

How it works

Warn about backslash escapes in ordinary string literals. It can be changed at session scope, so different sessions may observe different behavior.

When standard_conforming_strings is off, this warns about backslashes in ordinary strings so applications can migrate to standard literals or explicit E’…’ strings. It diagnoses legacy SQL; it does not change parsing by itself.

Monitor and change escape_string_warning together with array_nulls, backslash_quote, standard_conforming_strings. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG18; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

array_nulls · backslash_quote · standard_conforming_strings · transform_null_equals · quote_all_identifiers · default_with_oids

References

• PostgreSQL 18 — escape_string_warning
• Machine-readable GUC export

6 - lo_compat_privileges

Identity

Lifecycle

Default history

How it works

Enables backward compatibility mode for privilege checks on large objects. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

The compatibility mode restores pre-9.0 large-object privilege behavior for old applications. It weakens normal ownership/ACL enforcement around large objects and should be a temporary bridge while explicit GRANTs and ownership are corrected.

Monitor and change lo_compat_privileges together with default_with_oids, operator_precedence_warning, synchronize_seqscans. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

default_with_oids · operator_precedence_warning · synchronize_seqscans · standard_conforming_strings · array_nulls · backslash_quote

References

• PostgreSQL 19 Beta 3 — lo_compat_privileges
• PostgreSQL 19 release notes
• Machine-readable GUC export

7 - operator_precedence_warning

Identity

Lifecycle

Default history

How it works

Emit a warning for constructs that changed meaning since PostgreSQL 9.4. The parameter still exists in PG13 and is no longer recognized from PG14. PostgreSQL 14 removed the migration warning; rewrite ambiguous expressions with explicit parentheses and test them on the target release.

This emitted migration warnings for expressions whose operator binding changed in PostgreSQL 9.5. It never restored old precedence, and after its removal the durable fix is explicit parentheses plus regression tests.

Before upgrading, inspect default_with_oids, lo_compat_privileges, synchronize_seqscans, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG14 or later.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG13; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Continuing to emit unknown parameter operator_precedence_warning on PG14+.
• Deleting only the setting name without migrating dependent application behavior.
• Assuming the historical default equals the replacement mechanism’s default.
• Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Related parameters

default_with_oids · lo_compat_privileges · synchronize_seqscans · standard_conforming_strings · array_nulls · backslash_quote

References

• PostgreSQL 13 — operator_precedence_warning
• Machine-readable GUC export

8 - quote_all_identifiers

Identity

Lifecycle

Default history

How it works

When generating SQL fragments, quote all identifiers. It can be changed at session scope, so different sessions may observe different behavior.

This asks server-side SQL deparsers to double-quote every identifier instead of only those that require quoting. It helps transport SQL across keyword/version differences but does not quote values or make arbitrary string concatenation safe.

Monitor and change quote_all_identifiers together with array_nulls, backslash_quote, escape_string_warning. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

array_nulls · backslash_quote · escape_string_warning · standard_conforming_strings · transform_null_equals · default_with_oids

References

• PostgreSQL 19 Beta 3 — quote_all_identifiers
• PostgreSQL 19 release notes
• Machine-readable GUC export

9 - sql_inheritance

Identity

Lifecycle

Default history

How it works

PostgreSQL describes sql_inheritance as follows: “Causes subtables to be included by default in various commands.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. The atlas measures it in PG9.0–9.6; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

When enabled, this compatibility switch made commands operate on inheritance descendants unless ONLY was written. PostgreSQL 10 removed the switch: modern SQL uses ONLY to exclude descendants, while declarative partition pruning and constraint exclusion govern which child relations are scanned.

Read it together with constraint_exclusion, enable_partition_pruning, search_path, default_table_access_method. 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

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.6; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for sql_inheritance as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports user 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

constraint_exclusion · enable_partition_pruning · search_path · default_table_access_method

References

• PostgreSQL 9.6 — sql_inheritance
• Machine-readable GUC export

10 - standard_conforming_strings

Identity

Lifecycle

Default history

How it works

Causes ‘…’ strings to treat backslashes literally. It can be changed at session scope, so different sessions may observe different behavior.

With on, backslashes in ordinary ‘…’ strings are literal and escape processing requires E’…’. Turning it off restores legacy parsing, making client/server disagreement and unsafe SQL construction more likely.

Monitor and change standard_conforming_strings together with array_nulls, backslash_quote, escape_string_warning. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

array_nulls · backslash_quote · escape_string_warning · transform_null_equals · quote_all_identifiers · default_with_oids

References

• PostgreSQL 19 Beta 3 — standard_conforming_strings
• PostgreSQL 19 release notes
• Machine-readable GUC export

11 - synchronize_seqscans

Identity

Lifecycle

Default history

How it works

Enables synchronized sequential scans. It can be changed at session scope, so different sessions may observe different behavior.

Concurrent sequential scans of the same large relation may join a shared scan position, improving cache reuse while returning rows in a less predictable physical order. SQL without ORDER BY has no ordering guarantee regardless of this switch.

Monitor and change synchronize_seqscans together with default_with_oids, lo_compat_privileges, operator_precedence_warning. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

default_with_oids · lo_compat_privileges · operator_precedence_warning · standard_conforming_strings · array_nulls · backslash_quote

References

• PostgreSQL 19 Beta 3 — synchronize_seqscans
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - transform_null_equals

Identity

Lifecycle

Default history

How it works

Treats “expr=NULL” as “expr IS NULL”. It can be changed at session scope, so different sessions may observe different behavior.

The parser rewrites expr = NULL to expr IS NULL for broken legacy clients. SQL’s normal three-valued semantics make equality with NULL yield unknown, so enabling this can hide application defects and does not rewrite other NULL comparisons.

Monitor and change transform_null_equals together with array_nulls, backslash_quote, escape_string_warning. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Keeping a compatibility switch permanently instead of fixing the client.
• Testing in one session and deploying globally to unrelated applications.
• Confusing parsing compatibility with data or security compatibility.
• Forgetting to remove an override after the upgrade migration is complete.

Related parameters

array_nulls · backslash_quote · escape_string_warning · standard_conforming_strings · quote_all_identifiers · allow_alter_system

References

• PostgreSQL 19 Beta 3 — transform_null_equals
• PostgreSQL 19 release notes
• Machine-readable GUC export