Connections and Authentication

• 1: authentication_timeout
• 2: bonjour
• 3: bonjour_name
• 4: client_connection_check_interval
• 5: db_user_namespace
• 6: gss_accept_delegation
• 7: krb_caseins_users
• 8: krb_server_keyfile
• 9: krb_srvname
• 10: listen_addresses
• 11: max_connections
• 12: md5_password_warnings
• 13: oauth_validator_libraries
• 14: password_encryption
• 15: password_expiration_warning_threshold
• 16: port
• 17: reserved_connections
• 18: scram_iterations
• 19: ssl
• 20: ssl_ca_file
• 21: ssl_cert_file
• 22: ssl_ciphers
• 23: ssl_crl_dir
• 24: ssl_crl_file
• 25: ssl_dh_params_file
• 26: ssl_ecdh_curve
• 27: ssl_groups
• 28: ssl_key_file
• 29: ssl_max_protocol_version
• 30: ssl_min_protocol_version
• 31: ssl_passphrase_command
• 32: ssl_passphrase_command_supports_reload
• 33: ssl_prefer_server_ciphers
• 34: ssl_renegotiation_limit
• 35: ssl_sni
• 36: ssl_tls13_ciphers
• 37: superuser_reserved_connections
• 38: tcp_keepalives_count
• 39: tcp_keepalives_idle
• 40: tcp_keepalives_interval
• 41: tcp_user_timeout
• 42: unix_socket_directories
• 43: unix_socket_directory
• 44: unix_socket_group
• 45: unix_socket_permissions

1 - authentication_timeout

Identity

Lifecycle

Default history

How it works

authentication_timeout sets the maximum allowed time to complete client authentication. The timer covers the authentication exchange before a normal backend session is established, limiting slots consumed by stalled or malicious handshakes.

authentication_timeout is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

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

• Editing authentication_timeout without reloading configuration and verifying the effective value and subsequent behavior.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing authentication_timeout globally without a rollback plan and a client or operational compatibility test.

Related parameters

tcp_keepalives_idle · tcp_keepalives_interval · tcp_keepalives_count · tcp_user_timeout · client_connection_check_interval

References

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

2 - bonjour

Identity

Lifecycle

Default history

How it works

bonjour enables advertising the server via Bonjour. It publishes a discoverable service through mDNS only on builds and platforms with Bonjour support; it does not open a listener or alter pg_hba.conf.

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

Bonjour advertisement depends on platform support and publishes the listener as metadata; listen_addresses, port, pg_hba.conf, TLS, and firewalls still define actual reachability and trust.

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 bonjour, although it requires a controlled server restart.
• Treating an mDNS advertisement as an access-control, authentication, or high-availability mechanism.
• Publishing an unexpected service name or endpoint on an untrusted broadcast domain.
• Changing bonjour globally without a rollback plan and a client or operational compatibility test.

Related parameters

listen_addresses · port · max_connections · reserved_connections · superuser_reserved_connections · unix_socket_directories

References

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

3 - bonjour_name

Identity

Lifecycle

Default history

How it works

bonjour_name sets the Bonjour service name. An empty string means use the computer name. An empty value derives the advertised service name from the computer name, and the setting matters only when Bonjour advertisement is enabled.

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

Bonjour advertisement depends on platform support and publishes the listener as metadata; listen_addresses, port, pg_hba.conf, TLS, and firewalls still define actual reachability and trust.

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 bonjour_name, although it requires a controlled server restart.
• Treating an mDNS advertisement as an access-control, authentication, or high-availability mechanism.
• Publishing an unexpected service name or endpoint on an untrusted broadcast domain.
• Changing bonjour_name globally without a rollback plan and a client or operational compatibility test.

Related parameters

listen_addresses · port · max_connections · reserved_connections · superuser_reserved_connections · unix_socket_directories

References

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

4 - client_connection_check_interval

Identity

Lifecycle

Default history

How it works

client_connection_check_interval sets the time interval between checks for disconnection while running queries. 0 disables connection checks. A nonzero interval lets long-running queries notice a dead client before their next socket write; operating-system support determines whether checks are effective.

client_connection_check_interval 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 client_connection_check_interval 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 client_connection_check_interval globally without a rollback plan and a client or operational compatibility test.

Related parameters

tcp_keepalives_idle · tcp_keepalives_interval · tcp_keepalives_count · tcp_user_timeout · authentication_timeout

References

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

5 - db_user_namespace

Identity

Lifecycle

Default history

How it works

db_user_namespace enables per-database user names. This legacy feature represented users internally as user@database and was removed in PostgreSQL 17; it is not a modern tenant-isolation mechanism.

db_user_namespace is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

Tuning advice

Pigsty

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

Common pitfalls

• Editing db_user_namespace without reloading configuration and verifying the effective value and subsequent behavior.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing db_user_namespace globally without a rollback plan and a client or operational compatibility test.

Related parameters

password_encryption · scram_iterations · md5_password_warnings · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

• PostgreSQL 16 — db_user_namespace
• Machine-readable GUC export

6 - gss_accept_delegation

Identity

Lifecycle

Default history

How it works

gss_accept_delegation sets whether GSSAPI delegation should be accepted from the client. Accepting delegated credentials lets server-side code act with the client’s GSS identity, so it expands trust beyond ordinary authentication.

gss_accept_delegation is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

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

• Editing gss_accept_delegation without reloading configuration and verifying the effective value and subsequent behavior.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing gss_accept_delegation globally without a rollback plan and a client or operational compatibility test.

Related parameters

password_encryption · scram_iterations · md5_password_warnings · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

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

7 - krb_caseins_users

Identity

Lifecycle

Default history

How it works

krb_caseins_users sets whether Kerberos and GSSAPI user names should be treated as case-insensitive. It affects comparison of authenticated Kerberos/GSS names with database role names; case folding can merge identities that an existing mapping treated as distinct.

krb_caseins_users is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

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

• Editing krb_caseins_users without reloading configuration and verifying the effective value and subsequent behavior.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing krb_caseins_users globally without a rollback plan and a client or operational compatibility test.

Related parameters

password_encryption · scram_iterations · md5_password_warnings · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

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

8 - krb_server_keyfile

Identity

Lifecycle

Default history

How it works

krb_server_keyfile sets the location of the Kerberos server key file. The file contains service keys used by GSSAPI authentication; operating-system ownership and keytab rotation are part of the effective configuration.

krb_server_keyfile is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

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

• Editing krb_server_keyfile without reloading configuration and verifying the effective value and subsequent behavior.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing krb_server_keyfile globally without a rollback plan and a client or operational compatibility test.

Related parameters

password_encryption · scram_iterations · md5_password_warnings · authentication_timeout · oauth_validator_libraries

References

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

9 - krb_srvname

Identity

Lifecycle

Default history

How it works

PostgreSQL describes krb_srvname as follows: “Sets the name of the Kerberos service.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

This historical authentication setting selected the Kerberos service principal name used by the server. It disappeared after PostgreSQL 9.3; current deployments should derive their GSS/Kerberos design from pg_hba.conf, the keytab selected by krb_server_keyfile, DNS, and the client service-name options rather than carrying this obsolete server GUC forward.

Read it together with krb_server_keyfile, hba_file, ssl, password_encryption. 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.3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for krb_srvname 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

krb_server_keyfile · hba_file · ssl · password_encryption

References

• PostgreSQL 9.3 — krb_srvname
• Machine-readable GUC export

10 - listen_addresses

Identity

Lifecycle

Default history

How it works

listen_addresses sets the host name or IP address(es) to listen to. The server binds the listed interfaces at startup; reachability still depends on port, pg_hba.conf, host firewalls, and network routing.

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

The listener endpoint combines listen_addresses and port at startup, while pg_hba.conf, TLS, firewalls, routing, and service discovery determine which clients can use 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

• Expecting a reload or SET to activate listen_addresses, although it requires a controlled server restart.
• Assuming a bound address or port grants access; pg_hba.conf and operating-system or network controls still apply.
• Changing a startup-only endpoint without updating discovery, health checks, firewalls, clients, and the administrative recovery path.
• Changing listen_addresses globally without a rollback plan and a client or operational compatibility test.

Related parameters

port · max_connections · reserved_connections · superuser_reserved_connections · unix_socket_directories

References

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

11 - max_connections

Identity

Lifecycle

Default history

How it works

max_connections limits concurrent database-server connections and can only be changed at server start. PostgreSQL sizes some resources directly from it, so raising the ceiling increases allocations including shared memory even when not all slots are busy.

reserved_connections and superuser_reserved_connections carve emergency or privileged capacity out of the same overall ceiling. An application therefore cannot normally consume every configured slot.

A standby must use a value at least as high as its primary. Connection pooling can decouple large client populations from a smaller, controlled number of PostgreSQL backends.

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 the value without planning a restart and keeping standbys at least as high as the primary.
• Ignoring shared-memory and per-backend overhead created by a higher ceiling.
• Forgetting reserved and superuser-reserved slots when calculating application capacity.
• Combining a high connection ceiling with generous per-operation memory settings and assuming the product cannot occur.

Related parameters

reserved_connections · superuser_reserved_connections · work_mem · max_worker_processes · max_prepared_transactions · max_wal_senders

References

• PostgreSQL 19 Beta 3 — max_connections
• Pigsty: Parameter Templates
• Pigsty: Parameter Optimization Policy
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - md5_password_warnings

Identity

Lifecycle

Default history

How it works

md5_password_warnings controls a PostgreSQL 18 deprecation WARNING emitted when CREATE ROLE or ALTER ROLE sets an MD5-encrypted password. It does not report authentication with an existing MD5 verifier and is therefore not an inventory of active MD5 clients or roles.

It is a USER-context setting, so an authorized role can change it for the current session and ALTER ROLE or ALTER DATABASE can establish future-session defaults. The warning can only arise in a session that both performs a password-setting statement and has the setting enabled.

password_encryption controls the format generated when plaintext passwords are set, while existing pg_authid verifiers remain unchanged until their passwords are reset. Migration therefore needs a protected verifier inventory, client compatibility testing, and credential rotation in addition to this warning.

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

• Assuming the warning fires when an existing MD5 verifier is used for authentication; it fires only when CREATE ROLE or ALTER ROLE sets one.
• Using the absence of warnings as proof that the cluster has no MD5 secrets or MD5-only clients.
• Disabling the warning in deployment sessions that create or rotate roles and thereby hiding new MD5 verifier creation.
• Changing password_encryption without rotating existing role passwords, which leaves their stored verifier format unchanged.

Related parameters

password_encryption · scram_iterations · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

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

13 - oauth_validator_libraries

Identity

Lifecycle

Default history

How it works

oauth_validator_libraries lists trusted server modules that can validate OAuth 2.0 bearer tokens. PostgreSQL 18 ships no validator implementation, and the empty default refuses all OAuth connections; a usable deployment must install and name at least one compatible module.

With exactly one listed library, PostgreSQL uses it by default for OAuth connections. With multiple libraries, every oauth record in pg_hba.conf must name a validator selected from this list. The setting has SIGHUP context, so changing the allow-list requires a configuration reload and affects subsequent authentication attempts.

A validator executes trusted native code inside the server authentication path. Its token issuer, audience, claim-to-role mapping, failure behavior, dependencies, package version, and availability on every primary/failover node must agree with pg_hba.conf and the identity provider.

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

• Creating an oauth HBA rule while the list is empty; PostgreSQL will refuse every OAuth connection.
• Expecting PostgreSQL to provide a built-in validator implementation.
• Listing multiple libraries without selecting a validator in every oauth HBA record.
• Installing a validator on the primary but not on a failover target, or trusting native code whose issuer, audience, and role mapping were not reviewed.

Related parameters

password_encryption · scram_iterations · md5_password_warnings · authentication_timeout · krb_server_keyfile

References

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

14 - password_encryption

Identity

Lifecycle

Default history

How it works

password_encryption chooses the algorithm for encrypting passwords. It affects secrets generated by CREATE ROLE, ALTER ROLE, and password-setting commands; existing stored secrets are not rehashed automatically.

password_encryption 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.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

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 password_encryption in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.
• Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.
• Changing the algorithm and assuming existing role secrets are automatically converted.

Related parameters

scram_iterations · md5_password_warnings · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

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

15 - password_expiration_warning_threshold

Identity

Lifecycle

Default history

How it works

PostgreSQL describes password_expiration_warning_threshold as follows: “Threshold for password expiration warnings.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

After successful password authentication, PostgreSQL warns when a role with VALID UNTIL has less than this interval remaining. Zero disables the warning; the default seven-day window is advisory and does not create, rotate, or extend credentials, and non-password authentication does not make password expiry management automatic.

Read it together with password_encryption, authentication_timeout, md5_password_warnings, hba_file. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for password_expiration_warning_threshold 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.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

password_encryption · authentication_timeout · md5_password_warnings · hba_file

References

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

16 - port

Identity

Lifecycle

Default history

How it works

port sets the TCP port the server listens on. One port is used for every TCP listener address and becomes part of client connection strings, service discovery, firewall rules, and health checks.

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

The listener endpoint combines listen_addresses and port at startup, while pg_hba.conf, TLS, firewalls, routing, and service discovery determine which clients can use 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

• Expecting a reload or SET to activate port, although it requires a controlled server restart.
• Assuming a bound address or port grants access; pg_hba.conf and operating-system or network controls still apply.
• Changing a startup-only endpoint without updating discovery, health checks, firewalls, clients, and the administrative recovery path.
• Changing port globally without a rollback plan and a client or operational compatibility test.

Related parameters

listen_addresses · max_connections · reserved_connections · superuser_reserved_connections · unix_socket_directories

References

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

17 - reserved_connections

Identity

Lifecycle

Default history

How it works

reserved_connections sets the number of connection slots reserved for roles with privileges of pg_use_reserved_connections. These slots become available only to roles granted pg_use_reserved_connections and sit above ordinary capacity but below superuser-only reserves.

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

reserved_connections and superuser_reserved_connections carve privileged tiers from max_connections; poolers, monitoring, replication, maintenance, and failover must all fit the same total backend budget.

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 reserved_connections, although it requires a controlled server restart.
• Counting reserved slots outside max_connections even though every tier consumes the same total ceiling.
• Reserving too little for incident response or so much that ordinary application capacity collapses at saturation.
• Sizing ordinary, reserved, and superuser-reserved slots without ensuring their sum fits max_connections.

Related parameters

listen_addresses · port · max_connections · superuser_reserved_connections · unix_socket_directories

References

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

18 - scram_iterations

Identity

Lifecycle

Default history

How it works

scram_iterations is embedded in every newly generated SCRAM-SHA-256 verifier. Raising it increases offline-guessing cost but also increases legitimate password-setting and authentication work; existing verifiers keep the iteration count with which they were created until their passwords are reset.

It is a USER-context setting, so the session that executes CREATE ROLE or ALTER ROLE determines the count written into the new verifier. Role, database, or application-specific overrides can therefore create a mixture of counts even when postgresql.conf has one value.

PostgreSQL warns that when a role’s stored count differs from the configured server value, an unauthenticated observer can distinguish response behavior and infer that the role exists. A count change therefore requires uniform session policy and rotation of all SCRAM verifiers, not only a GUC edit.

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 the GUC without resetting existing passwords; their verifiers retain the old count.
• Allowing role or database session defaults to generate verifiers with counts different from postgresql.conf, creating a role-existence side channel.
• Raising the count without load-testing authentication storms, failover, pooler reconnects, and password rotation jobs.
• Assuming a higher count repairs weak passwords or compensates for leaked verifier material.

Related parameters

password_encryption · md5_password_warnings · authentication_timeout · oauth_validator_libraries · krb_server_keyfile

References

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

19 - ssl

Identity

Lifecycle

Default history

How it works

ssl enables SSL connections. Turning it on makes TLS listeners available when certificate and key material are valid; pg_hba.conf hostssl rules are what require TLS for selected clients.

ssl is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

20 - ssl_ca_file

Identity

Lifecycle

Default history

How it works

ssl_ca_file identifies the location of the SSL certificate authority file. The PEM CA bundle defines trust roots for client-certificate verification and the acceptable-authority list sent during TLS negotiation.

ssl_ca_file is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_ca_file without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_ca_file globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl · ssl_cert_file · ssl_key_file · ssl_crl_file · ssl_min_protocol_version

References

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

21 - ssl_cert_file

Identity

Lifecycle

Default history

How it works

ssl_cert_file identifies the location of the SSL server certificate file. The PEM file supplies the server leaf certificate and may include intermediate certificates needed to present a complete chain to clients.

ssl_cert_file is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_cert_file without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_cert_file globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

22 - ssl_ciphers

Identity

Lifecycle

Default history

How it works

The ssl_ciphers name already exists in PostgreSQL’s GUC source at the project’s 2008 history boundary and in PG9.0, where it is compiled only under USE_SSL. The audited PG9.0 fallback build does not enable OpenSSL, so the name first appears in the PG9.1 official-image snapshot; that matrix boundary reflects build capability, not the feature’s original invention.

The OpenSSL cipher string governs TLS 1.2 and older handshakes. PostgreSQL 18 and later configure TLS 1.3 suites separately with ssl_tls13_ciphers. A SIGHUP reload changes the policy for new TLS contexts and connections but does not renegotiate sessions that are already established.

Treat ssl_ciphers as one part of a complete transport policy with ssl, pg_hba.conf, certificate and key files, CA and revocation settings, protocol floors and ceilings, ssl_groups, and client capabilities. Validate the exact installed OpenSSL build because accepted cipher names and security levels are library-dependent.

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

• Editing ssl_ciphers without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_ciphers globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_tls13_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

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

23 - ssl_crl_dir

Identity

Lifecycle

Default history

How it works

ssl_crl_dir names a directory of client-certificate revocation lists. OpenSSL requires hashed lookup links, so the directory must be prepared again with openssl rehash or c_rehash whenever CRLs are added or replaced. It supplements ssl_crl_file; both sources can be active.

Changing the directory path is a SIGHUP-context configuration change, but CRL files inside the configured directory are loaded on demand at connection time. A newly installed and correctly rehashed CRL can therefore be used immediately by new connections without a PostgreSQL reload.

This differs from ssl_crl_file, whose file content is loaded at server startup or configuration reload. Existing TLS sessions are not retroactively revoked by either setting; test revocation with a fresh client-certificate handshake and monitor CRL issuer, signature, and expiry.

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

• Adding or replacing a CRL without running openssl rehash or c_rehash, leaving it undiscoverable by OpenSSL.
• Reloading PostgreSQL but not refreshing an expired CRL, or assuming a directory change applies retroactively to established TLS sessions.
• Treating ssl_crl_dir like ssl_crl_file and missing that directory CRLs are loaded on demand for new connections.
• Synchronizing the directory path but not its CRLs and hash links to every failover node.

Related parameters

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

24 - ssl_crl_file

Identity

Lifecycle

Default history

How it works

ssl_crl_file identifies the location of the SSL certificate revocation list file. The PEM revocation list is consulted when validating client certificates and must be refreshed as issuers publish new revocation state.

ssl_crl_file is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_crl_file without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_crl_file globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_min_protocol_version

References

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

25 - ssl_dh_params_file

Identity

Lifecycle

Default history

How it works

ssl_dh_params_file identifies the location of the SSL DH parameters file. An empty string means use compiled-in default parameters. An empty value uses PostgreSQL’s compiled-in DH parameters; the file matters only for cipher suites that perform finite-field Diffie-Hellman exchange.

ssl_dh_params_file is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_dh_params_file without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_dh_params_file globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

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

26 - ssl_ecdh_curve

Identity

Lifecycle

Default history

How it works

ssl_ecdh_curve sets the curve to use for ECDH. This single-curve control existed through PostgreSQL 17 and was replaced in PostgreSQL 18 by the multi-group ssl_groups setting.

ssl_ecdh_curve is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

Tuning advice

Pigsty

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

Common pitfalls

• Editing ssl_ecdh_curve without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Leaving the removed name in PostgreSQL 18 configuration instead of migrating to ssl_groups.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

• PostgreSQL 17 — ssl_ecdh_curve
• Machine-readable GUC export

27 - ssl_groups

Identity

Lifecycle

Default history

How it works

ssl_groups sets the group(s) to use for Diffie-Hellman key exchange. Multiple groups can be specified using a colon-separated list. PostgreSQL 18 accepts an ordered colon-separated list, replacing the former single ssl_ecdh_curve choice and covering supported key-exchange groups.

ssl_groups is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_groups without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_groups globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_prefer_server_ciphers

References

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

28 - ssl_key_file

Identity

Lifecycle

Default history

How it works

ssl_key_file identifies the location of the SSL server private key file. The file contains the private key matching ssl_cert_file; PostgreSQL enforces restrictive ownership and permissions before accepting it.

ssl_key_file is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_key_file without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Installing a private key with ownership or permissions that PostgreSQL rejects, or leaking it to a readable group.

Related parameters

ssl · ssl_cert_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

29 - ssl_max_protocol_version

Identity

Lifecycle

Default history

How it works

ssl_max_protocol_version sets the maximum SSL/TLS protocol version to use. An empty value imposes no PostgreSQL-specific ceiling beyond the SSL library, while a named version can intentionally block newer protocols for compatibility testing.

ssl_max_protocol_version is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_max_protocol_version without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_max_protocol_version globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_min_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

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

30 - ssl_min_protocol_version

Identity

Lifecycle

Default history

How it works

ssl_min_protocol_version sets the minimum SSL/TLS protocol version to use. Connections negotiating below the floor are rejected; the upstream default moved from TLSv1 in PostgreSQL 12 to TLSv1.2 in PostgreSQL 13.

ssl_min_protocol_version is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_min_protocol_version without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Changing ssl_min_protocol_version globally without a rollback plan and a client or operational compatibility test.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_max_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

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

31 - ssl_passphrase_command

Identity

Lifecycle

Default history

How it works

ssl_passphrase_command is an external helper invoked when PostgreSQL must decrypt an SSL file such as an encrypted private key. The helper must write the passphrase to standard output and exit with status zero; PostgreSQL strips one trailing newline from the output.

Within the configured command, %p is replaced by a prompt string that can contain whitespace and therefore must be quoted safely; %% emits a literal percent. The command runs as the PostgreSQL service account, and its environment, path, arguments, output, and error logging must not expose the secret.

It has SIGHUP context, but whether an encrypted key can be replaced during reload also depends on ssl_passphrase_command_supports_reload. A noninteractive keychain/file helper can support reload; a TTY prompt is normally suitable only for controlled startup, and Windows has additional reload requirements.

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

• Printing anything except the passphrase to standard output or returning a nonzero status.
• Failing to quote %p even though the substituted prompt can contain whitespace, or forgetting that %% is required for a literal percent.
• Exposing the passphrase through command arguments, process listings, environment variables, shell tracing, stderr, or server logs.
• Deploying a helper that works interactively on one primary but fails during unattended restart, reload, or failover.

Related parameters

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

32 - ssl_passphrase_command_supports_reload

Identity

Lifecycle

Default history

How it works

ssl_passphrase_command_supports_reload decides whether ssl_passphrase_command may be invoked during configuration reload when a replacement SSL key needs a passphrase. When it is off, the command is ignored during reload and PostgreSQL does not reload the SSL configuration if a passphrase is required.

The setting has SIGHUP context and affects replacement TLS material used by new handshakes; existing TLS sessions are not renegotiated. It should be on only when the helper is noninteractive, reliably available, and safe to invoke in the running server environment.

On Windows this setting must be on, because the Windows process model causes every connection to perform a configuration reload. That platform requirement overrides the usual Unix-oriented choice to keep a TTY-dependent helper startup-only.

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

• Setting it to off on Windows, where PostgreSQL requires it to be on because each connection performs a configuration reload.
• Enabling reload support while the passphrase helper is interactive, slow, unavailable, or unsafe to invoke repeatedly.
• Assuming a reload renegotiates existing sessions; replacement TLS material affects new handshakes only.
• Failing to inspect server logs after reload; if passphrase retrieval fails, PostgreSQL keeps the previous SSL configuration.

Related parameters

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version

References

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

33 - ssl_prefer_server_ciphers

Identity

Lifecycle

Default history

How it works

ssl_prefer_server_ciphers gives priority to server ciphersuite order. It affects server-versus-client ordering only for TLS 1.2 and older; TLS 1.3 negotiation does not use this switch.

ssl_prefer_server_ciphers is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_prefer_server_ciphers without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Assuming it controls TLS 1.3 cipher ordering.

Related parameters

ssl_ciphers · ssl_tls13_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_groups

References

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

34 - ssl_renegotiation_limit

Identity

Lifecycle

Default history

How it works

PostgreSQL describes ssl_renegotiation_limit as follows: “Set the amount of traffic to send and receive before renegotiating the encryption keys.” 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.4; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

This setting initiated TLS key renegotiation after a traffic threshold. PostgreSQL removed it in 9.5 as protocol/library behavior and security guidance moved away from renegotiation; modern TLS policy should use supported protocol versions, ciphers, certificates, and ordinary connection rotation.

Read it together with ssl_min_protocol_version, ssl_max_protocol_version, ssl_ciphers, ssl. 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.4; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for ssl_renegotiation_limit 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

ssl_min_protocol_version · ssl_max_protocol_version · ssl_ciphers · ssl

References

• PostgreSQL 9.4 — ssl_renegotiation_limit
• Machine-readable GUC export

35 - ssl_sni

Identity

Lifecycle

Default history

How it works

PostgreSQL describes ssl_sni as follows: “Sets whether to interpret SNI extensions in SSL connections.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

When enabled with TLS, PostgreSQL reads the client’s Server Name Indication and selects credentials through hosts_file. Hostnames match case-insensitively; /no_sni/ and * provide explicit fallback behavior. Certificate identity, client verification, CRLs, permissions, and reload failures still require independent validation.

Read it together with hosts_file, ssl, ssl_cert_file, ssl_key_file. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for ssl_sni 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.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

hosts_file · ssl · ssl_cert_file · ssl_key_file · ssl_ca_file

References

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

36 - ssl_tls13_ciphers

Identity

Lifecycle

Default history

How it works

ssl_tls13_ciphers sets the list of allowed TLSv1.3 cipher suites. An empty string means use the default cipher suites. An empty value delegates TLS 1.3 suite selection to the SSL library default, and the syntax is distinct from ssl_ciphers.

ssl_tls13_ciphers is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value. Existing TLS sessions are not renegotiated.

It participates in the TLS context used for new handshakes. ssl enables transport, pg_hba.conf decides which connection classes require it, and the certificate, key, CA, revocation, protocol, and cipher settings must form one valid policy.

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

• Editing ssl_tls13_ciphers without reloading configuration and verifying the effective value and subsequent behavior.
• Updating only one TLS file or policy knob and leaving an invalid chain, unreadable key, or incompatible protocol set.
• Assuming a reload renegotiates existing sessions; TLS policy changes affect new handshakes.
• Using ssl_ciphers syntax or names for TLS 1.3 and unintentionally rejecting every intended suite.

Related parameters

ssl_ciphers · ssl_min_protocol_version · ssl_max_protocol_version · ssl_prefer_server_ciphers · ssl_groups

References

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

37 - superuser_reserved_connections

Identity

Lifecycle

Default history

How it works

superuser_reserved_connections sets the number of connection slots reserved for superusers. These slots are usable only after ordinary and reserved_connections capacity is exhausted, preserving an emergency path for superusers.

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

reserved_connections and superuser_reserved_connections carve privileged tiers from max_connections; poolers, monitoring, replication, maintenance, and failover must all fit the same total backend budget.

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 superuser_reserved_connections, although it requires a controlled server restart.
• Counting reserved slots outside max_connections even though every tier consumes the same total ceiling.
• Reserving too little for incident response or so much that ordinary application capacity collapses at saturation.
• Changing superuser_reserved_connections globally without a rollback plan and a client or operational compatibility test.

Related parameters

listen_addresses · port · max_connections · reserved_connections · unix_socket_directories

References

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

38 - tcp_keepalives_count