track_activity_query_size
Read PG 18 manual ↗Specifies the amount of memory reserved to store the text of the currently executing command for each active session, for the pg_stat_activity.query field.
- Type
- integer
- Context
- postmaster
- Measured default
- 1 KiB
- Unit
- B
- Metadata snapshot
- 18
Definition PG 18 manual
Specifies the amount of memory reserved to store the text of the currently executing command for each active session, for the pg_stat_activity.query field. If this value is specified without units, it is taken as bytes. The default value is 1024 bytes. This parameter can only be set at server start.
Measured default history
| Version interval | Default |
|---|---|
| 9.0 – 10 | 1024 |
| 11 – 19 | 1 KiB |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
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.
Operational considerations
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.
Workload guidance
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.
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.
SMALL: 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.
Version history 6
- PG 14 → 15changed
- PG 13 → 14changed
- PG 12 → 13changed
- PG 11 → 12changed
- PG 10 → 11changed
- PG 9.1 → 9.2changed
Related entries
Further reading
Definition snapshot: english-manuals:4baa02fa9d487262ad26eac2545… · English manual source