Reporting and Logging

• 1: application_name
• 2: cluster_name
• 3: debug_pretty_print
• 4: debug_print_parse
• 5: debug_print_plan
• 6: debug_print_raw_parse
• 7: debug_print_rewritten
• 8: event_source
• 9: log_autoanalyze_min_duration
• 10: log_autovacuum_min_duration
• 11: log_checkpoints
• 12: log_connections
• 13: log_destination
• 14: log_directory
• 15: log_disconnections
• 16: log_duration
• 17: log_error_verbosity
• 18: log_file_mode
• 19: log_filename
• 20: log_hostname
• 21: log_line_prefix
• 22: log_lock_failures
• 23: log_lock_waits
• 24: log_min_duration_sample
• 25: log_min_duration_statement
• 26: log_min_error_statement
• 27: log_min_messages
• 28: log_parameter_max_length
• 29: log_parameter_max_length_on_error
• 30: log_recovery_conflict_waits
• 31: log_replication_commands
• 32: log_rotation_age
• 33: log_rotation_size
• 34: log_startup_progress_interval
• 35: log_statement
• 36: log_statement_sample_rate
• 37: log_temp_files
• 38: log_timezone
• 39: log_transaction_sample_rate
• 40: log_truncate_on_rotation
• 41: logging_collector
• 42: silent_mode
• 43: syslog_facility
• 44: syslog_ident
• 45: syslog_sequence_numbers
• 46: syslog_split_messages
• 47: update_process_title

1 - application_name

Identity

Lifecycle

Default history

How it works

application_name is client-supplied session metadata, usually set in the startup packet or later with SET. It appears in pg_stat_activity and CSV logs and can be inserted into text logs with the %a escape in log_line_prefix.

The value is shorter than NAMEDATALEN bytes (64 characters in a standard build). PostgreSQL permits printable ASCII; other characters are rendered as C-style hexadecimal escapes. Truncation and escaping mean log consumers must not assume the displayed value exactly matches an application’s original string.

It is a USER-context label and is not authenticated identity: any authorized client can claim a misleading value and a pooled session can retain or overwrite it. Correlate it with authenticated user, database, session ID, remote endpoint, and controlled pool checkout/reset behavior.

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 application_name as authenticated identity or using it alone for authorization, billing, or audit attribution.
• Exceeding NAMEDATALEN and silently losing distinguishing suffixes through truncation.
• Assuming arbitrary Unicode is preserved rather than escaped to printable C-style hexadecimal sequences.
• Leaking secrets or creating unbounded cardinality in logs and pg_stat_activity, or failing to reset the value in a connection pool.

Related parameters

cluster_name · update_process_title · log_line_prefix · log_timezone · log_hostname

References

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

2 - cluster_name

Identity

Lifecycle

Default history

How it works

cluster_name sets the name of the cluster, which is included in the process title. It is an operator-facing label included in process titles and can distinguish several clusters running on one host; it is not a database identifier.

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

Process titles complement application_name, cluster_name, pg_stat_activity, and log_line_prefix, allowing operating-system observations to be joined with database activity.

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 cluster_name, although it requires a controlled server restart.
• Putting secrets or unbounded high-cardinality data into operator-visible process labels.
• Using inconsistent cluster, application, and process labels that cannot be joined across monitoring systems.
• Changing cluster_name globally without a rollback plan and a client or operational compatibility test.

Related parameters

application_name · update_process_title · log_line_prefix · log_timezone · log_hostname

References

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

3 - debug_pretty_print

Identity

Lifecycle

Default history

How it works

debug_pretty_print indents parse and plan tree displays. It changes only the indentation of internal parse and plan tree dumps produced by the debug_print_* switches.

debug_pretty_print 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 debug_print_* switches feed the normal server logging path, so log_min_messages, log_destination, and collector capacity determine whether the output is retained safely.

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 debug_pretty_print in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Leaving an internal-tree dump enabled globally and overwhelming log I/O, storage, or ingestion.
• Treating debug output as a stable public format or as a substitute for targeted EXPLAIN diagnostics.
• Changing debug_pretty_print globally without a rollback plan and a client or operational compatibility test.

Related parameters

debug_print_parse · debug_print_plan · debug_print_rewritten · log_min_messages · client_min_messages

References

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

4 - debug_print_parse

Identity

Lifecycle

Default history

How it works

debug_print_parse logs each query’s parse tree. The output is PostgreSQL’s internal parse-tree representation for every parsed query, not normalized SQL text.

debug_print_parse 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 debug_print_* switches feed the normal server logging path, so log_min_messages, log_destination, and collector capacity determine whether the output is retained safely.

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 debug_print_parse in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Leaving an internal-tree dump enabled globally and overwhelming log I/O, storage, or ingestion.
• Treating debug output as a stable public format or as a substitute for targeted EXPLAIN diagnostics.
• Changing debug_print_parse globally without a rollback plan and a client or operational compatibility test.

Related parameters

debug_pretty_print · debug_print_plan · debug_print_rewritten · log_min_messages · client_min_messages

References

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

5 - debug_print_plan

Identity

Lifecycle

Default history

How it works

debug_print_plan logs each query’s execution plan. The output is an internal plan tree for every query and is much more verbose than a targeted EXPLAIN; it is intended for server debugging.

debug_print_plan 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 debug_print_* switches feed the normal server logging path, so log_min_messages, log_destination, and collector capacity determine whether the output is retained safely.

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 debug_print_plan in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Leaving an internal-tree dump enabled globally and overwhelming log I/O, storage, or ingestion.
• Treating debug output as a stable public format or as a substitute for targeted EXPLAIN diagnostics.
• Changing debug_print_plan globally without a rollback plan and a client or operational compatibility test.

Related parameters

debug_pretty_print · debug_print_parse · debug_print_rewritten · log_min_messages · client_min_messages

References

• PostgreSQL 19 release notes
• Machine-readable GUC export

6 - debug_print_raw_parse

Identity

Lifecycle

Default history

How it works

PostgreSQL describes debug_print_raw_parse as follows: “Logs each query’s raw parse tree.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. 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.

The raw parse tree is emitted before parse analysis, rewriting, planning, and execution. Messages use LOG level; debug_pretty_print changes formatting, while client_min_messages and log_min_messages determine where they are visible. Output can be very large and can expose query text structure.

Read it together with debug_print_parse, debug_print_rewritten, debug_print_plan, debug_pretty_print. 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 debug_print_raw_parse 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.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

debug_print_parse · debug_print_rewritten · debug_print_plan · debug_pretty_print · log_min_messages

References

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

7 - debug_print_rewritten

Identity

Lifecycle

Default history

How it works

debug_print_rewritten logs each query’s rewritten parse tree. It exposes the query tree after rule rewriting, which is useful for diagnosing views and rules but can generate very large logs.

debug_print_rewritten 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 debug_print_* switches feed the normal server logging path, so log_min_messages, log_destination, and collector capacity determine whether the output is retained safely.

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 debug_print_rewritten in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Leaving an internal-tree dump enabled globally and overwhelming log I/O, storage, or ingestion.
• Treating debug output as a stable public format or as a substitute for targeted EXPLAIN diagnostics.
• Changing debug_print_rewritten globally without a rollback plan and a client or operational compatibility test.

Related parameters

debug_pretty_print · debug_print_parse · debug_print_plan · log_min_messages · client_min_messages

References

• PostgreSQL 19 release notes
• Machine-readable GUC export

8 - event_source

Identity

Lifecycle

Default history

How it works

event_source sets the application name used to identify PostgreSQL messages in the event log. This is a Windows event-log identifier and has no effect unless eventlog is an active log destination.

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

event_source is consulted only on Windows when eventlog is selected in log_destination; Windows Event Log registration, permissions, routing, and retention supply the rest of the pipeline.

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 event_source, although it requires a controlled server restart.
• Changing the source name without registering or updating Windows Event Log routing and access policy.
• Expecting event_source to have any effect when eventlog is not an active log destination or the platform is not Windows.
• Changing event_source globally without a rollback plan and a client or operational compatibility test.

Related parameters

logging_collector · log_destination · log_directory · log_filename · log_rotation_age · log_rotation_size

References

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

9 - log_autoanalyze_min_duration

Identity

Lifecycle

Default history

How it works

PostgreSQL describes log_autoanalyze_min_duration as follows: “Sets the minimum execution time above which analyze actions by autovacuum will be logged.” 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.

Zero logs every automatic ANALYZE, -1 disables these duration messages, and a positive value logs actions meeting the threshold plus relevant skips caused by locks or dropped relations. Per-table storage parameters can override it, independently from log_autovacuum_min_duration for VACUUM actions.

Read it together with log_autovacuum_min_duration, autovacuum, autovacuum_analyze_threshold, autovacuum_analyze_scale_factor. 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 log_autoanalyze_min_duration 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

log_autovacuum_min_duration · autovacuum · autovacuum_analyze_threshold · autovacuum_analyze_scale_factor · log_min_messages

References

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

10 - log_autovacuum_min_duration

Identity

Lifecycle

Default history

How it works

log_autovacuum_min_duration sets the minimum execution time above which autovacuum actions will be logged. -1 disables logging autovacuum actions. 0 means log all autovacuum actions. Each qualifying automatic VACUUM or ANALYZE emits timing and work details; -1 disables these completion records and zero records every action.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_autovacuum_min_duration without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_autovacuum_min_duration globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_checkpoints · log_lock_waits · log_lock_failures · log_temp_files · log_replication_commands

References

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

11 - log_checkpoints

Identity

Lifecycle

Default history

How it works

log_checkpoints logs each checkpoint. A checkpoint record includes elapsed phases and buffer or WAL work, exposing checkpoint cadence and write pressure rather than merely a marker.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_checkpoints without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_checkpoints globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_autovacuum_min_duration · log_lock_waits · log_lock_failures · log_temp_files · log_replication_commands

References

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

12 - log_connections

Identity

Lifecycle

Default history

How it works

In PostgreSQL 10–17, log_connections is a Boolean that logs successful connections when enabled. PostgreSQL 18 changed it to a string list whose exact options are receipt, authentication, authorization, setup_durations, and all; the empty string disables connection logging. For compatibility, on, true, yes, and 1 mean receipt,authentication,authorization, while off, false, no, and 0 mean the empty list. Failed authentication is logged regardless of this setting.

log_connections has SUPERUSER_BACKEND context: it may be selected by a superuser or a role with the appropriate SET privilege at session start, but it cannot be changed after the backend session has started. A configuration change therefore affects new sessions only.

receipt records arrival, authentication records the original identity presented by the authentication method, authorization records successful authorization with user/database/application context, and setup_durations records total setup, backend-fork, and authentication timing. log_disconnections controls session-end records separately; connection identities and topology remain sensitive log data.

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

• Using setup instead of the valid PostgreSQL 18 option setup_durations.
• Assuming the compatibility value on means all; it omits setup_durations and maps only to receipt, authentication, and authorization.
• Expecting existing sessions to inherit a changed value even though the setting is fixed at backend startup.
• Treating duplicate receipt records as attacks without accounting for clients such as psql that can probe twice, or retaining original identities without an access-control policy.

Related parameters

log_statement · log_duration · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error

References

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

13 - log_destination

Identity

Lifecycle

Default history

How it works

log_destination sets the destination for server log output. Valid values are combinations of “stderr”, “syslog”, “csvlog”, “jsonlog”, and “eventlog”, depending on the platform. Several destinations can be active at once; csvlog and jsonlog require logging_collector, while stderr, syslog, and Windows eventlog follow different transport paths.

log_destination 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 active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

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 log_destination without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Changing log_destination globally without a rollback plan and a client or operational compatibility test.

Related parameters

logging_collector · log_directory · log_filename · log_rotation_age · log_rotation_size

References

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

14 - log_directory

Identity

Lifecycle

Default history

How it works

log_directory sets the destination directory for log files. Can be specified as relative to the data directory or as absolute path. A relative path is resolved below the data directory, while an absolute path can place collector-managed files on a separate filesystem.

log_directory 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 active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

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 log_directory without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Changing log_directory globally without a rollback plan and a client or operational compatibility test.

Related parameters

logging_collector · log_destination · log_filename · log_rotation_age · log_rotation_size

References

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

15 - log_disconnections

Identity

Lifecycle

Default history

How it works

log_disconnections logs end of a session, including duration. The record is emitted at session end and includes session duration, pairing naturally with connection-start identity but not proving that every abrupt failure reached the logger.

log_disconnections has SUPERUSER_BACKEND context: configuration changes apply when a new backend session starts and require superuser-level authority; established sessions keep their startup value.

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 existing sessions to inherit a new log_disconnections value even though it is fixed when each backend starts.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_disconnections globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_statement · log_duration · log_connections · log_parameter_max_length · log_parameter_max_length_on_error

References

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

16 - log_duration

Identity

Lifecycle

Default history

How it works

log_duration logs the duration of each completed SQL statement. It emits a duration for every completed statement but does not itself emit statement text; log_statement or a duration threshold supplies text when required.

log_duration 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_duration in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Expecting duration records to contain SQL text when no statement-logging setting emits that text.

Related parameters

log_statement · log_connections · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error

References

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

17 - log_error_verbosity

Identity

Lifecycle

Default history

How it works

log_error_verbosity sets the verbosity of logged messages. TERSE suppresses detail and hints, DEFAULT retains normal diagnostics, and VERBOSE adds SQLSTATE plus source file, function, and line information.

log_error_verbosity 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_error_verbosity in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_error_verbosity globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_statement · log_duration · log_connections · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error

References

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

18 - log_file_mode

Identity

Lifecycle

Default history

How it works

log_file_mode is a chmod-style numeric mode for files newly created by logging_collector. Use a leading zero for customary octal notation: 0640 is not the same numeric value as decimal 640. The setting does not apply to syslog/eventlog output and does not change existing files.

It has SIGHUP context. After a reload, the new mode is used the next time logging_collector creates a file; reloading does not chmod the file that is currently open or historical files.

The effective access boundary also includes the PostgreSQL service account, file group, log_directory ownership and traversal permissions, shipping-agent group membership, and external retention copies. A group-readable mode is safe only when that group is controlled.

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 log_file_mode without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Writing 640 instead of octal 0640 and producing a different numeric permission mode.

Related parameters

logging_collector · log_destination · log_directory · log_filename · log_rotation_age · log_rotation_size

References

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

19 - log_filename

Identity

Lifecycle

Default history

How it works

log_filename sets the file name pattern for log files. logging_collector expands strftime escapes using log_timezone whenever it opens a new file, so repeating names must be coordinated with rotation and truncation.

log_filename 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 active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

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 log_filename without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Using a repeating strftime name without matching rotation and truncation policy, causing append growth or overwrite surprises.

Related parameters

logging_collector · log_destination · log_directory · log_rotation_age · log_rotation_size

References

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

20 - log_hostname

Identity

Lifecycle

Default history

How it works

log_hostname logs the host name in the connection logs. By default, connection logs only show the IP address of the connecting host. If you want them to show the host name you can turn this on, but depending on your host name resolution setup it might impose a non-negligible performance penalty. Reverse DNS is performed to turn client addresses into names, which can add connection latency or stalls when name service is slow.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_hostname without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Turning on reverse DNS where resolver latency lies on the connection path.

Related parameters

application_name · cluster_name · update_process_title · log_line_prefix · log_timezone

References

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

21 - log_line_prefix

Identity

Lifecycle

Default history

How it works

log_line_prefix controls information prefixed to each log line. An empty string means no prefix. Percent escapes add session, user, database, process, application, and timing context; csvlog and jsonlog already carry structured fields separately.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_line_prefix without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Omitting process, session, database, user, or application identity needed to correlate multiline text logs.

Related parameters

application_name · cluster_name · update_process_title · log_timezone · log_hostname

References

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

22 - log_lock_failures

Identity

Lifecycle

Default history

How it works

log_lock_failures was introduced in PostgreSQL 18 to emit a detailed message when a supported lock acquisition fails. In PostgreSQL 18 the supported scope is specifically lock failure caused by SELECT … NOWAIT; it is not a general logger for every NOWAIT-like command or every lock error.

It is a SUPERUSER-context setting. A superuser or a role with the appropriate SET privilege can change it per session, so role/database defaults and connection-pool reset behavior determine which sessions produce records.

It complements log_lock_waits: log_lock_waits reports waits that cross deadlock_timeout, whereas SELECT … NOWAIT fails immediately and can be reported here. The detailed message can expose relation, lock, and statement context and must follow the normal log access 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

• Assuming PostgreSQL 18 logs every lock acquisition failure; currently only SELECT … NOWAIT is supported.
• Using it instead of log_lock_waits even though immediate failure and a wait exceeding deadlock_timeout are different events.
• Enabling it in one pooled session and assuming other sessions inherited the value.
• Retaining detailed lock and statement context without appropriate log access, redaction, and retention controls.

Related parameters

log_checkpoints · log_autovacuum_min_duration · log_lock_waits · log_temp_files · log_replication_commands

References

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

23 - log_lock_waits

Identity

Lifecycle

Default history

How it works

log_lock_waits logs long lock waits. A wait is logged after deadlock_timeout, so the diagnostic threshold and deadlock detector cadence are coupled.

log_lock_waits 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_lock_waits in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing deadlock_timeout without realizing it also changes when lock-wait diagnostics appear.

Related parameters

log_checkpoints · log_autovacuum_min_duration · log_lock_failures · log_temp_files · log_replication_commands

References

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

24 - log_min_duration_sample

Identity

Lifecycle

Default history

How it works

log_min_duration_sample admits completed statements at or above its duration threshold into stochastic logging controlled by log_statement_sample_rate. -1 disables this path, zero admits every completed statement, and the sample rate then decides which admitted statements are emitted.

log_min_duration_statement has higher priority. A statement that reaches its threshold is always logged and is not sampled, even if it also exceeds log_min_duration_sample. Under the extended query protocol, Parse, Bind, and Execute durations are logged separately.

It is a SUPERUSER-context session setting. Sampled entries have the same statement-text, Bind-value, correlation, overhead, and security considerations as log_min_duration_statement, so log_line_prefix and log_parameter_max_length still determine usefulness and exposure.

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 sampling to affect statements already captured by the higher-priority log_min_duration_statement threshold.
• Forgetting that Parse, Bind, and Execute are timed and logged separately with the extended query protocol.
• Setting zero with log_statement_sample_rate = 1 and unintentionally logging every completed statement duration.
• Sampling SQL and Bind values without correlation identifiers, redaction, access control, and a measured volume budget.

Related parameters

log_min_messages · log_min_error_statement · log_min_duration_statement · log_statement_sample_rate · log_transaction_sample_rate

References

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

25 - log_min_duration_statement

Identity

Lifecycle

Default history

How it works

The value is a duration in milliseconds when no unit is written. A value of -1 disables duration-based statement logging, zero logs every completed statement, and a positive value logs statements at or above the threshold.

Statements selected by this setting are always logged rather than sampled, so it takes priority over log_min_duration_sample. Under the extended query protocol, Parse, Bind, and Execute durations can appear separately.

This parameter observes and records completed work; it does not stop slow statements. statement_timeout is the separate execution-cancellation control.

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

• Low thresholds on high-throughput systems can create extreme log volume and I/O.
• SQL text can contain sensitive literals and must be protected like application data.
• It logs slow statements but does not cancel them; use statement_timeout for that goal.
• Extended-protocol phases may be logged separately and need session or PID correlation.
• Interactions with log_statement, sampling, and log_line_prefix can confuse duplicate or fragmented entries.

Related parameters

log_min_duration_sample · log_statement_sample_rate · log_statement · log_duration · log_line_prefix · statement_timeout

References

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

26 - log_min_error_statement

Identity

Lifecycle

Default history

How it works

log_min_error_statement causes all statements generating error at or above this level to be logged. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. It governs whether the SQL statement associated with an error-level message is included; log_min_messages separately decides whether the message itself is emitted.

log_min_error_statement 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_min_error_statement in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_min_error_statement globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_min_messages · log_min_duration_statement · log_min_duration_sample · log_statement_sample_rate · log_transaction_sample_rate

References

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

27 - log_min_messages

Identity

Lifecycle

Default history

How it works

log_min_messages sets the message levels that are logged. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The server-log severity ordering has special placement for LOG and differs from client_min_messages, so a threshold name cannot be copied blindly between them.

log_min_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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_min_messages in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_min_messages globally without a rollback plan and a client or operational compatibility test.

Related parameters

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 — log_min_messages
• PostgreSQL 19 release notes
• Machine-readable GUC export

28 - log_parameter_max_length

Identity

Lifecycle

Default history

How it works

log_parameter_max_length controls Bind values attached to non-error statement-logging messages. Zero suppresses them, -1 allows full values, and a positive byte count truncates each textual value to that limit.

It applies to messages produced by log_statement, log_min_duration_statement, and related statement-logging settings. Any nonzero value adds work; parameters sent in binary form must be converted to text before they can be logged.

It is a SUPERUSER-context session setting and is independent of log_parameter_max_length_on_error. The normal and error paths therefore need separate confidentiality and overhead decisions.

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

• Using -1 and exposing complete credentials, tokens, or large payloads in normal statement logs.
• Treating truncation as redaction; a sensitive prefix can remain fully visible.
• Ignoring text-conversion overhead for binary Bind parameters when the value is nonzero.
• Assuming this setting also limits error-path parameters controlled by log_parameter_max_length_on_error.

Related parameters

log_statement · log_duration · log_connections · log_disconnections · log_parameter_max_length_on_error

References

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

29 - log_parameter_max_length_on_error

Identity

Lifecycle

Default history

How it works

log_parameter_max_length_on_error controls Bind values included in error reports. Zero, the default, suppresses them; -1 permits complete values; a positive byte count truncates each textual value to that limit.

For any nonzero value PostgreSQL must preserve textual parameter representations at the start of every statement in case an error occurs. That overhead is paid even by successful statements, and binary parameters require conversion rather than a simple text copy.

It is a USER-context session setting and is independent of log_parameter_max_length, so an application can accidentally expose values on errors even when normal statement logging suppresses them. Error detail, access, redaction, and retention must be reviewed 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

• Assuming the conversion and memory cost is paid only when a statement fails; every statement pays it when the value is nonzero.
• Using -1 and exposing complete secrets or large payloads in error reports.
• Ignoring textual conversion cost for binary Bind values and retained representations for successful statements.
• Assuming log_parameter_max_length also protects error paths; the two limits are independent.

Related parameters

log_statement · log_duration · log_connections · log_disconnections · log_parameter_max_length

References

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

30 - log_recovery_conflict_waits

Identity

Lifecycle

Default history

How it works

log_recovery_conflict_waits logs standby recovery conflict waits. On a standby, recovery conflict waits are reported after deadlock_timeout, exposing replay delays before cancellation is necessarily required.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_recovery_conflict_waits without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_recovery_conflict_waits globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_checkpoints · log_autovacuum_min_duration · log_lock_waits · log_lock_failures · log_temp_files · log_replication_commands

References

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

31 - log_replication_commands

Identity

Lifecycle

Default history

How it works

log_replication_commands logs each replication command. It covers replication-protocol commands as well as SQL replication commands and can therefore expose replication topology and slot activity.

log_replication_commands 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_replication_commands in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_replication_commands globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_checkpoints · log_autovacuum_min_duration · log_lock_waits · log_lock_failures · log_temp_files

References

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

32 - log_rotation_age

Identity

Lifecycle

Default history

How it works

log_rotation_age sets the amount of time to wait before forcing log file rotation. 0 disables time-based creation of new log files. The collector opens a new file after the interval; zero disables this trigger but leaves size-based or external rotation possible.

log_rotation_age 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 active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

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 log_rotation_age without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Changing log_rotation_age globally without a rollback plan and a client or operational compatibility test.

Related parameters

logging_collector · log_destination · log_directory · log_filename · log_rotation_size

References

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

33 - log_rotation_size

Identity

Lifecycle

Default history

How it works

log_rotation_size sets the maximum size a log file can reach before being rotated. 0 disables size-based creation of new log files. The collector rotates when the current file reaches approximately this size; zero disables the size trigger but not time-based rotation.

log_rotation_size 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 active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

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 log_rotation_size without reloading configuration and verifying the effective value and subsequent behavior.
• Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
• Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
• Setting zero without a working time-based or external rotation policy and allowing unbounded growth.

Related parameters

logging_collector · log_destination · log_directory · log_filename · log_rotation_age

References

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

34 - log_startup_progress_interval

Identity

Lifecycle

Default history

How it works

log_startup_progress_interval defines the interval between progress updates for long-running startup operations. 0 disables progress updates. Startup processes emit periodic progress for operations such as WAL replay when they exceed the interval; zero disables these updates.

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

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_startup_progress_interval without reloading configuration and verifying the effective value and subsequent behavior.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Changing log_startup_progress_interval globally without a rollback plan and a client or operational compatibility test.

Related parameters

log_checkpoints · log_autovacuum_min_duration · log_lock_waits · log_lock_failures · log_temp_files · log_replication_commands

References

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

35 - log_statement

Identity

Lifecycle

Default history

How it works

log_statement selects none, ddl, mod, or all. ddl logs data-definition commands; mod adds data-changing commands; all logs every statement that reaches the logging point. PREPARE, EXECUTE, and EXPLAIN ANALYZE follow the contained command’s class.

With the extended query protocol, logging occurs when Execute is received and includes Bind parameter values. Even all does not log a simple statement that fails basic parsing, nor an extended-protocol statement that fails before Execute during parse analysis or planning; log_min_error_statement is required for those error paths.

It is a SUPERUSER-context session setting. Statement text and Bind values can expose personal data, tokens, and even plaintext passwords, so selection, access, redaction, transport, and retention must be treated as a security control as well as an observability choice.

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 all captures syntax errors or extended-protocol failures before Execute; use log_min_error_statement for those paths.
• Forgetting that extended-protocol Execute logging includes Bind parameter values.
• Logging SQL that contains plaintext passwords, bearer tokens, personal data, or application secrets without redaction and strict access controls.
• Enabling mod or all cluster-wide without bounding log throughput, disk, shipping, and retention.

Related parameters

log_duration · log_connections · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error

References

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

36 - log_statement_sample_rate

Identity

Lifecycle

Default history

How it works

log_statement_sample_rate sets the fraction of statements exceeding “log_min_duration_sample” to be logged. Use a value between 0.0 (never log) and 1.0 (always log). This probability is evaluated only for statements admitted by log_min_duration_sample; it does not sample log_statement or log_min_duration_statement output.

log_statement_sample_rate 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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 log_statement_sample_rate in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
• Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
• Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
• Expecting it to sample all statement logging even though it only gates log_min_duration_sample.

Related parameters

log_min_messages · log_min_error_statement · log_min_duration_statement · log_min_duration_sample · log_transaction_sample_rate

References

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

37 - log_temp_files

Identity

Lifecycle

Default history

How it works

log_temp_files logs the use of temporary files larger than this number of kilobytes. -1 disables logging temporary files. 0 means log all temporary files. A temporary file is reported when it is deleted, with its name and size; -1 disables records and zero includes every file.

log_temp_files 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 emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

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.