track_activity_query_size

track_activity_query_size — Sets the size reserved for pg_stat_activity.query, in bytes. Observed in PG9.0–19 Beta 3; its last measured boot default is 1 KiB in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the size reserved for pg_stat_activity.query, in bytes.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , ValueB: Raw unit
Range , Value100 – 1048576: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueStatistics / Cumulative Query and Index Statistics: Upstream classification
Latest boot value , Value1024: 1 KiB

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–10	`1024`	—	1024
PG11–19 Beta 3	`1024`	`B`	1 KiB

How it works

track_activity_query_size reserves real shared memory for the current-query text of every active session shown in pg_stat_activity.query. It is a byte count fixed at server start.

Long statements are truncated to this storage size; increasing it improves incident context but multiplies memory by the number of backend slots, including configured connection capacity.

It does not change log statement length, pg_stat_statements query-text storage, or application payload limits. Query identifiers can correlate truncated text with other telemetry when compute_query_id is available. Its postmaster context fixes the value at server start; changing it requires a restart.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Choose enough bytes to retain diagnostically useful SQL, then budget approximately that storage across all backend slots rather than active queries alone. Increasing it is a startup shared-memory decision and requires a restart.
OLAP	Long generated SQL often needs more than 1kB to remain identifiable. Compare truncation frequency and incident needs against the value multiplied by MaxBackends; this setting incurs memory, not repeated clock-read overhead.
Small nodes	Keep the smallest value that preserves useful statement identity. Do not copy a 32kB critical-profile value without multiplying it across connection and worker slots on the small host.

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.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`8192`	different	`8192`
OLAP	`8192`	different	`8192`
CRIT	`32768`	different	`32768`
TINY	`8192`	different	`8192`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 8192 (dcs); OLAP: PG9.0–19 Beta 3 = 8192 (dcs); CRIT: PG9.0–19 Beta 3 = 32768 (dcs); TINY: PG9.0–19 Beta 3 = 8192 (dcs). Advice, pending human review — Editorial inference, pending maintainer review: The templates retain more query text than upstream for operations, with a larger critical-profile value intended to preserve full diagnostic context.

Common pitfalls

Treating the value as memory only for currently active queries instead of storage reserved across backend slots.
Forgetting that the unit is bytes and multibyte query text can contain fewer characters than the byte count suggests.
Expecting it to change log statement length or pg_stat_statements query-text storage.
Changing it without the required server restart.

track_activities · max_connections · compute_query_id · log_line_prefix · shared_buffers