Client Connection Defaults

• 1: DateStyle
• 2: IntervalStyle
• 3: TimeZone
• 4: bytea_output
• 5: check_function_bodies
• 6: client_encoding
• 7: client_min_messages
• 8: createrole_self_grant
• 9: default_table_access_method
• 10: default_tablespace
• 11: default_text_search_config
• 12: default_toast_compression
• 13: default_transaction_deferrable
• 14: default_transaction_isolation
• 15: default_transaction_read_only
• 16: dynamic_library_path
• 17: event_triggers
• 18: extension_control_path
• 19: extra_float_digits
• 20: gin_fuzzy_search_limit
• 21: gin_pending_list_limit
• 22: icu_validation_level
• 23: idle_in_transaction_session_timeout
• 24: idle_session_timeout
• 25: jit_provider
• 26: lc_messages
• 27: lc_monetary
• 28: lc_numeric
• 29: lc_time
• 30: local_preload_libraries
• 31: lock_timeout
• 32: restrict_nonsystem_relation_kind
• 33: row_security
• 34: search_path
• 35: session_preload_libraries
• 36: session_replication_role
• 37: shared_preload_libraries
• 38: statement_timeout
• 39: temp_tablespaces
• 40: timezone_abbreviations
• 41: transaction_deferrable
• 42: transaction_isolation
• 43: transaction_read_only
• 44: transaction_timeout
• 45: vacuum_cleanup_index_scale_factor
• 46: xmlbinary
• 47: xmloption

1 - DateStyle

Identity

Lifecycle

Default history

How it works

DateStyle sets the display format for date and time values. Also controls interpretation of ambiguous date inputs. The value has two independent parts: an output style and a DMY/MDY/YMD field order; the latter also resolves ambiguous input.

DateStyle is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing DateStyle in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Parsing an ambiguous value such as 01/02/03 under an unexpected MDY/DMY order.

Related parameters

IntervalStyle · TimeZone · lc_time · timezone_abbreviations · log_timezone

References

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

2 - IntervalStyle

Identity

Lifecycle

Default history

How it works

IntervalStyle sets the display format for interval values. Its four modes target PostgreSQL compatibility, verbose output, SQL-standard literals, or ISO 8601; it can also change how ambiguous interval input is read.

IntervalStyle is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing IntervalStyle in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing IntervalStyle globally without a rollback plan and a client or operational compatibility test.

Related parameters

DateStyle · TimeZone · lc_time · timezone_abbreviations · log_timezone

References

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

3 - TimeZone

Identity

Lifecycle

Default history

How it works

TimeZone sets the time zone for displaying and interpreting time stamps. It affects timestamptz rendering and timestamp input lacking an explicit zone, while the stored instant remains independent of the display zone.

TimeZone is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing TimeZone in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Comparing rendered timestamps without preserving the original instant and explicit zone context.

Related parameters

DateStyle · IntervalStyle · lc_time · timezone_abbreviations · log_timezone

References

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

4 - bytea_output

Identity

Lifecycle

Default history

How it works

bytea_output sets the output format for bytea. The choice affects textual output only: bytea input accepts both hex and escape syntax regardless of this setting.

bytea_output is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing bytea_output in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing bytea_output globally without a rollback plan and a client or operational compatibility test.

Related parameters

extra_float_digits · xmlbinary · xmloption · client_encoding · DateStyle

References

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

5 - check_function_bodies

Identity

Lifecycle

Default history

How it works

check_function_bodies checks routine bodies during CREATE FUNCTION and CREATE PROCEDURE. Turning it off suppresses creation-time validation, which is useful for dump restores and forward references but defers errors until execution.

check_function_bodies is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

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

• Changing check_function_bodies in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Expecting a changed default to rewrite existing objects or override explicit DDL clauses.
• Ignoring tablespace privileges, installed access methods or compression support, and restore portability.
• Changing check_function_bodies globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_table_access_method · default_tablespace · temp_tablespaces · default_toast_compression · maintenance_work_mem

References

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

6 - client_encoding

Identity

Lifecycle

Default history

How it works

client_encoding sets the client’s character set encoding. PostgreSQL converts text between this encoding and the database encoding when a supported conversion exists; SQL_ASCII disables useful validation rather than identifying a real character set.

client_encoding is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing client_encoding in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Using SQL_ASCII as if it were an encoding and allowing invalid byte sequences to cross the client boundary.

Related parameters

lc_messages · lc_monetary · lc_numeric · lc_time · default_text_search_config

References

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

7 - client_min_messages

Identity

Lifecycle

Default history

How it works

client_min_messages sets the message levels that are sent to the client. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The threshold governs messages returned to the client, not messages written to the server log, and INFO is delivered regardless of the chosen threshold.

client_min_messages is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It affects the client protocol’s diagnostic stream, while log_min_messages and log_min_error_statement independently control server-side records; INFO remains a special always-sent level.

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

• Changing client_min_messages in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Copying severity expectations from log_min_messages even though the client ordering treats LOG differently and always sends INFO.
• Suppressing warnings globally and hiding deprecations or operational guidance that applications should surface.
• Changing client_min_messages globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_min_messages · log_min_error_statement · log_min_duration_statement · log_min_duration_sample · log_statement_sample_rate · log_transaction_sample_rate

References

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

8 - createrole_self_grant

Identity

Lifecycle

Default history

How it works

createrole_self_grant sets whether a CREATEROLE user automatically grants the role to themselves, and with which options. An empty string disables automatic self grants. The accepted options are set, inherit, or both; it automates a grant the creating CREATEROLE user could issue with ADMIN OPTION and does not affect superusers.

createrole_self_grant is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing createrole_self_grant in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Changing createrole_self_grant globally without a rollback plan and a client or operational compatibility test.

Related parameters

search_path · row_security · session_replication_role · event_triggers · restrict_nonsystem_relation_kind

References

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

9 - default_table_access_method

Identity

Lifecycle

Default history

How it works

default_table_access_method sets the default table access method for new tables. It is consulted only when CREATE TABLE, CREATE MATERIALIZED VIEW, or SELECT INTO does not name an access method; existing relations are unchanged.

default_table_access_method is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

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

• Changing default_table_access_method in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Expecting a changed default to rewrite existing objects or override explicit DDL clauses.
• Ignoring tablespace privileges, installed access methods or compression support, and restore portability.
• Changing default_table_access_method globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_tablespace · temp_tablespaces · default_toast_compression · check_function_bodies · maintenance_work_mem

References

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

10 - default_tablespace

Identity

Lifecycle

Default history

How it works

default_tablespace sets the default tablespace to create tables and indexes in. An empty string means use the database’s default tablespace. It selects the destination for new persistent tables and indexes, not temporary objects or CREATE DATABASE; an invalid configured name falls back to the database default in some contexts.

default_tablespace is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

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

• Changing default_tablespace in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Expecting a changed default to rewrite existing objects or override explicit DDL clauses.
• Ignoring tablespace privileges, installed access methods or compression support, and restore portability.
• Changing default_tablespace globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_table_access_method · temp_tablespaces · default_toast_compression · check_function_bodies · maintenance_work_mem

References

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

11 - default_text_search_config

Identity

Lifecycle

Default history

How it works

default_text_search_config sets default text search configuration. Text-search functions use it only when the caller omits an explicit configuration; initdb may choose a locale-matching value instead of the built-in simple configuration.

default_text_search_config is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing default_text_search_config in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing default_text_search_config globally without a rollback plan and a client or operational compatibility test.

Related parameters

client_encoding · lc_messages · lc_monetary · lc_numeric · lc_time

References

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

12 - default_toast_compression

Identity

Lifecycle

Default history

How it works

default_toast_compression sets the default compression method for compressible values. It chooses pglz or, when compiled in, lz4 for newly written compressible values; a column COMPRESSION clause overrides the session default.

default_toast_compression is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

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

• Changing default_toast_compression in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Expecting a changed default to rewrite existing objects or override explicit DDL clauses.
• Ignoring tablespace privileges, installed access methods or compression support, and restore portability.
• Changing default_toast_compression globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_table_access_method · default_tablespace · temp_tablespaces · check_function_bodies · maintenance_work_mem

References

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

13 - default_transaction_deferrable

Identity

Lifecycle

Default history

How it works

default_transaction_deferrable sets the default deferrable status of new transactions. The default matters only for read-only serializable transactions, which may wait for a safe snapshot and then avoid serialization failures.

default_transaction_deferrable is a USER-context setting and can be assigned per role, database, or session; its value is copied when a new transaction starts, so it does not rewrite a transaction already in progress.

The default_* variables seed the corresponding transaction_* state. Isolation, read-only status, deferrability, retries, and snapshot lifetime must be designed together.

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

• Changing default_transaction_deferrable in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Changing transaction semantics as a performance experiment and silently weakening an application’s consistency contract.
• Letting a pooled session retain transaction-related state because checkout or rollback/reset handling is incomplete.
• Changing default_transaction_deferrable globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_transaction_isolation · transaction_isolation · default_transaction_read_only · transaction_read_only · transaction_deferrable

References

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

14 - default_transaction_isolation

Identity

Lifecycle

Default history

How it works

default_transaction_isolation sets the transaction isolation level of each new transaction. PostgreSQL copies this value into transaction_isolation when each transaction begins; it changes consistency semantics, not merely performance.

default_transaction_isolation is a USER-context setting and can be assigned per role, database, or session; its value is copied when a new transaction starts, so it does not rewrite a transaction already in progress.

The default_* variables seed the corresponding transaction_* state. Isolation, read-only status, deferrability, retries, and snapshot lifetime must be designed together.

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

• Changing default_transaction_isolation in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Changing transaction semantics as a performance experiment and silently weakening an application’s consistency contract.
• Letting a pooled session retain transaction-related state because checkout or rollback/reset handling is incomplete.
• Changing default_transaction_isolation globally without a rollback plan and a client or operational compatibility test.

Related parameters

transaction_isolation · default_transaction_read_only · transaction_read_only · default_transaction_deferrable · transaction_deferrable

References

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

15 - default_transaction_read_only

Identity

Lifecycle

Default history

How it works

default_transaction_read_only sets the default read-only status of new transactions. Each transaction inherits this default, but read-only mode still permits temporary-table changes and does not substitute for standby or privilege enforcement.

default_transaction_read_only is a USER-context setting and can be assigned per role, database, or session; its value is copied when a new transaction starts, so it does not rewrite a transaction already in progress.

The default_* variables seed the corresponding transaction_* state. Isolation, read-only status, deferrability, retries, and snapshot lifetime must be designed together.

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

• Changing default_transaction_read_only in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Changing transaction semantics as a performance experiment and silently weakening an application’s consistency contract.
• Letting a pooled session retain transaction-related state because checkout or rollback/reset handling is incomplete.
• Changing default_transaction_read_only globally without a rollback plan and a client or operational compatibility test.

Related parameters

default_transaction_isolation · transaction_isolation · transaction_read_only · default_transaction_deferrable · transaction_deferrable

References

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

16 - dynamic_library_path

Identity

Lifecycle

Default history

How it works

dynamic_library_path sets the path for dynamically loadable modules. If a dynamically loadable module needs to be opened and the specified name does not have a directory component (i.e., the name does not contain a slash), the system will search this path for the specified file. The search is used only for module names without a directory component; $libdir points at PostgreSQL’s version-specific library directory.

dynamic_library_path is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Changing dynamic_library_path in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing dynamic_library_path globally without a rollback plan and a client or operational compatibility test.

Related parameters

shared_preload_libraries · session_preload_libraries · local_preload_libraries · jit_provider · extension_control_path

References

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

17 - event_triggers

Identity

Lifecycle

Default history

How it works

event_triggers enables event triggers. When enabled, event triggers will fire for all applicable statements. The switch disables all event triggers as an emergency repair aid; it is not a selective trigger policy and requires elevated SET privilege.

event_triggers is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing event_triggers in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Changing event_triggers globally without a rollback plan and a client or operational compatibility test.

Related parameters

search_path · row_security · session_replication_role · restrict_nonsystem_relation_kind · createrole_self_grant

References

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

18 - extension_control_path

Identity

Lifecycle

Default history

How it works

extension_control_path sets the path for extension control files. The remaining extension script and secondary control files are then loaded from the same directory where the primary control file was found. PostgreSQL searches this path for an extension’s primary control file, then loads its scripts and secondary control files from the directory where that primary file was found.

extension_control_path is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Changing extension_control_path in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing extension_control_path globally without a rollback plan and a client or operational compatibility test.

Related parameters

shared_preload_libraries · session_preload_libraries · local_preload_libraries · dynamic_library_path · jit_provider

References

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

19 - extra_float_digits

Identity

Lifecycle

Default history

How it works

extra_float_digits sets the number of digits displayed for floating-point values. This affects real, double precision, and geometric data types. A zero or negative parameter value is added to the standard number of digits (FLT_DIG or DBL_DIG as appropriate). Any value greater than zero selects precise output mode. Since PostgreSQL 12, positive values select shortest-precise output; zero and negative values request rounded legacy output and can lose round-trip fidelity.

extra_float_digits is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing extra_float_digits in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Carrying pre-12 assumptions forward even though positive values now select shortest-precise output.

Related parameters

bytea_output · xmlbinary · xmloption · client_encoding · DateStyle

References

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

20 - gin_fuzzy_search_limit

Identity

Lifecycle

Default history

How it works

gin_fuzzy_search_limit sets the maximum allowed result for exact search by GIN. 0 means no limit. A positive limit makes broad GIN searches return a randomly chosen subset of matches, trading completeness for bounded work; zero preserves exact results.

gin_fuzzy_search_limit is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

GIN behavior also depends on per-index storage parameters, work or maintenance memory, autovacuum, and the shape of indexed values and predicates.

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

• Changing gin_fuzzy_search_limit in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Applying a cluster-wide GIN value to fix one exceptional index instead of using its storage parameters.
• Ignoring cleanup latency, I/O bursts, autovacuum interaction, or result completeness while tuning.
• Enabling a positive limit without telling callers that exact searches may return an incomplete random subset.

Related parameters

gin_pending_list_limit · maintenance_work_mem · work_mem · vacuum_cleanup_index_scale_factor · autovacuum_work_mem

References

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

21 - gin_pending_list_limit

Identity

Lifecycle

Default history

How it works

gin_pending_list_limit sets the maximum size of the pending list for GIN index. With a GIN index’s fastupdate enabled, crossing this limit triggers bulk migration from the pending list into the main index; per-index storage parameters can override it.

gin_pending_list_limit is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

GIN behavior also depends on per-index storage parameters, work or maintenance memory, autovacuum, and the shape of indexed values and predicates.

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

• Changing gin_pending_list_limit in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Applying a cluster-wide GIN value to fix one exceptional index instead of using its storage parameters.
• Ignoring cleanup latency, I/O bursts, autovacuum interaction, or result completeness while tuning.
• Changing gin_pending_list_limit globally without a rollback plan and a client or operational compatibility test.

Related parameters

gin_fuzzy_search_limit · maintenance_work_mem · work_mem · vacuum_cleanup_index_scale_factor · autovacuum_work_mem

References

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

22 - icu_validation_level

Identity

Lifecycle

Default history

How it works

icu_validation_level sets the log level for reporting invalid ICU locale strings. The setting changes how invalid ICU locale identifiers are reported, including the option to suppress reporting or escalate it to an error.

icu_validation_level is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing icu_validation_level in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing icu_validation_level globally without a rollback plan and a client or operational compatibility test.

Related parameters

client_encoding · lc_messages · lc_monetary · lc_numeric · lc_time · default_text_search_config

References

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

23 - idle_in_transaction_session_timeout

Identity

Lifecycle

Default history

How it works

idle_in_transaction_session_timeout sets the maximum allowed idle time between queries, when in a transaction. 0 disables the timeout. It terminates sessions idle inside an open transaction, releasing locks and old snapshots that can block vacuum cleanup and cause bloat.

idle_in_transaction_session_timeout is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Timeouts overlap: the first applicable deadline wins, while client, pooler, TCP, and server cancellation behavior determines whether work is retried, canceled, or the session is closed.

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

• Changing idle_in_transaction_session_timeout in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Forgetting that zero usually disables the timeout or delegates behavior to the operating system.
• Setting overlapping deadlines without deciding which layer owns retries, cancellation, and connection disposal.
• Changing idle_in_transaction_session_timeout globally without a rollback plan and a client or operational compatibility test.

Related parameters

statement_timeout · lock_timeout · transaction_timeout · idle_session_timeout · deadlock_timeout

References

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

24 - idle_session_timeout

Identity

Lifecycle

Default history

How it works

idle_session_timeout sets the maximum allowed idle time between queries, when not in a transaction. 0 disables the timeout. It closes sessions idle outside a transaction; such sessions are usually cheap, and poolers may react badly to unexpected server-side closure.

idle_session_timeout is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Timeouts overlap: the first applicable deadline wins, while client, pooler, TCP, and server cancellation behavior determines whether work is retried, canceled, or the session is closed.

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

• Changing idle_session_timeout in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Forgetting that zero usually disables the timeout or delegates behavior to the operating system.
• Setting overlapping deadlines without deciding which layer owns retries, cancellation, and connection disposal.
• Changing idle_session_timeout globally without a rollback plan and a client or operational compatibility test.

Related parameters

statement_timeout · lock_timeout · transaction_timeout · idle_in_transaction_session_timeout · deadlock_timeout

References

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

25 - jit_provider

Identity

Lifecycle

Default history

How it works

jit_provider selects the JIT provider. The named provider supplies PostgreSQL’s JIT implementation and must be binary-compatible; changing the provider requires a server restart.

jit_provider is a POSTMASTER-context setting: PostgreSQL reads it during server startup, and a configuration reload or session SET cannot activate a new value.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Expecting a reload or SET to activate jit_provider, although it requires a controlled server restart.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing jit_provider globally without a rollback plan and a client or operational compatibility test.

Related parameters

shared_preload_libraries · session_preload_libraries · local_preload_libraries · dynamic_library_path · extension_control_path

References

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

26 - lc_messages

Identity

Lifecycle

Default history

How it works

lc_messages sets the language in which messages are displayed. An empty string means use the operating system setting. The accepted locale names and available translations are operating-system and build dependent; an empty value inherits the server environment.

lc_messages is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing lc_messages in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing lc_messages globally without a rollback plan and a client or operational compatibility test.

Related parameters

client_encoding · lc_monetary · lc_numeric · lc_time · default_text_search_config

References

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

27 - lc_monetary

Identity

Lifecycle

Default history

How it works

lc_monetary sets the locale for formatting monetary amounts. An empty string means use the operating system setting. It affects monetary formatting functions such as to_char, not the numeric value stored in a money or numeric column.

lc_monetary is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing lc_monetary in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing lc_monetary globally without a rollback plan and a client or operational compatibility test.

Related parameters

client_encoding · lc_messages · lc_numeric · lc_time · default_text_search_config

References

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

28 - lc_numeric

Identity

Lifecycle

Default history

How it works

lc_numeric sets the locale for formatting numbers. An empty string means use the operating system setting. It affects locale-sensitive numeric formatting such as decimal and grouping symbols, but ordinary SQL numeric literals retain SQL syntax.

lc_numeric is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing lc_numeric in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing lc_numeric globally without a rollback plan and a client or operational compatibility test.

Related parameters

client_encoding · lc_messages · lc_monetary · lc_time · default_text_search_config

References

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

29 - lc_time

Identity

Lifecycle

Default history

How it works

lc_time sets the locale for formatting date and time values. An empty string means use the operating system setting. It controls locale-sensitive names and layouts used by formatting functions; DateStyle and TimeZone remain separate controls.

lc_time is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes representation, parsing, or locale behavior at the client boundary rather than physical storage. Coordinate it with the other locale and formatting settings and with driver-native binary or typed protocols.

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

• Changing lc_time in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Assuming a presentation setting changes stored values or server-side type semantics.
• Changing a role or database default without testing text-parsing clients, exports, and pooled sessions.
• Changing lc_time globally without a rollback plan and a client or operational compatibility test.

Related parameters

DateStyle · IntervalStyle · TimeZone · timezone_abbreviations · log_timezone

References

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

30 - local_preload_libraries

Identity

Lifecycle

Default history

How it works

local_preload_libraries lists unprivileged shared libraries to preload into each backend. Unprivileged users may name only libraries installed in PostgreSQL’s plugins subdirectory, making package placement part of the security boundary.

Although local_preload_libraries is configurable without a server restart, its library list is acted on only when a new backend starts; changing it inside an established connection does not unload or retroactively load modules.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Changing local_preload_libraries in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing local_preload_libraries globally without a rollback plan and a client or operational compatibility test.

Related parameters

shared_preload_libraries · session_preload_libraries · dynamic_library_path · jit_provider · extension_control_path

References

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

31 - lock_timeout

Identity

Lifecycle

Default history

How it works

lock_timeout sets the maximum allowed duration of any wait for a lock. 0 disables the timeout. The timer applies separately to each lock acquisition, not to total statement runtime; a statement_timeout at the same or lower value will fire first.

lock_timeout is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Timeouts overlap: the first applicable deadline wins, while client, pooler, TCP, and server cancellation behavior determines whether work is retried, canceled, or the session is closed.

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

• Changing lock_timeout in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Forgetting that zero usually disables the timeout or delegates behavior to the operating system.
• Setting overlapping deadlines without deciding which layer owns retries, cancellation, and connection disposal.
• Changing lock_timeout globally without a rollback plan and a client or operational compatibility test.

Related parameters

statement_timeout · transaction_timeout · idle_in_transaction_session_timeout · idle_session_timeout · deadlock_timeout

References

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

32 - restrict_nonsystem_relation_kind

Identity

Lifecycle

Default history

How it works

restrict_nonsystem_relation_kind prohibits access to non-system relations of specified kinds. The supported kinds are view and foreign-table; PostgreSQL uses the restriction as a safety boundary for specialized sessions, not as general SQL authorization.

restrict_nonsystem_relation_kind is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing restrict_nonsystem_relation_kind in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Changing restrict_nonsystem_relation_kind globally without a rollback plan and a client or operational compatibility test.

Related parameters

search_path · row_security · session_replication_role · event_triggers · createrole_self_grant

References

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

33 - row_security

Identity

Lifecycle

Default history

How it works

row_security enables row security. When enabled, row security will be applied to all users. Off does not bypass policies for ordinary roles: it raises an error where a policy would apply, which lets tools such as pg_dump avoid silently incomplete results.

row_security is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing row_security in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Setting off expecting a bypass, although ordinary roles receive an error when a policy would apply.

Related parameters

search_path · session_replication_role · event_triggers · restrict_nonsystem_relation_kind · createrole_self_grant

References

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

34 - search_path

Identity

Lifecycle

Default history

How it works

search_path sets the schema search order for names that are not schema-qualified. It controls both lookup and the target schema for unqualified CREATE; pg_catalog and the temporary schema have special implicit search rules.

search_path is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing search_path in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Placing a schema writable by an untrusted role before trusted schemas and enabling object-shadowing attacks.

Related parameters

row_security · session_replication_role · event_triggers · restrict_nonsystem_relation_kind · createrole_self_grant

References

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

35 - session_preload_libraries

Identity

Lifecycle

Default history

How it works

session_preload_libraries lists shared libraries to preload into each backend. The list is loaded into each new matching backend and may be set only by a superuser or an appropriately privileged role; a missing library rejects the connection.

Although session_preload_libraries is configurable without a server restart, its library list is acted on only when a new backend starts; changing it inside an established connection does not unload or retroactively load modules.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Changing session_preload_libraries in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing session_preload_libraries globally without a rollback plan and a client or operational compatibility test.

Related parameters

shared_preload_libraries · local_preload_libraries · dynamic_library_path · jit_provider · extension_control_path

References

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

36 - session_replication_role

Identity

Lifecycle

Default history

How it works

session_replication_role sets the session’s behavior for triggers and rewrite rules. replica suppresses ordinary triggers and rules, including foreign-key enforcement, and changing the value discards cached plans.

session_replication_role is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control’s effective boundary.

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

• Changing session_replication_role in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.
• Failing to reset a security-sensitive session value before a pooled connection is reused by another request.
• Forgetting that replica mode suppresses foreign-key triggers as well as application triggers.

Related parameters

search_path · row_security · event_triggers · restrict_nonsystem_relation_kind · createrole_self_grant

References

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

37 - shared_preload_libraries

Identity

Lifecycle

Default history

How it works

shared_preload_libraries lists shared libraries to preload into server. Libraries load once in the postmaster before shared memory is finalized, enabling hooks and shared state unavailable to later LOAD; one missing library prevents server startup.

shared_preload_libraries is a POSTMASTER-context setting: PostgreSQL reads it during server startup, and a configuration reload or session SET cannot activate a new value.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

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

• Expecting a reload or SET to activate shared_preload_libraries, although it requires a controlled server restart.
• Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
• Treating a search or preload path as harmless even though it defines which native code the server trusts.
• Changing shared_preload_libraries globally without a rollback plan and a client or operational compatibility test.

Related parameters

session_preload_libraries · local_preload_libraries · dynamic_library_path · jit_provider · extension_control_path

References

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

38 - statement_timeout

Identity