select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / CLIENT CONNECTION DEFAULTS

transaction_deferrable

Read PG 18 manual ↗

This parameter reflects the current transaction's deferrability status.

Type
bool
Context
user
Measured default
off
Unit
Metadata snapshot
18

Definition PG 18 manual

This parameter reflects the current transaction's deferrability status. At the beginning of each transaction, it is set to the current value of default_transaction_deferrable. Any subsequent attempt to change it is equivalent to a SET TRANSACTION command.

Measured default history
Version intervalDefault
9.1 – 19off
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

transaction_deferrable controls whether PostgreSQL should defer a read-only serializable transaction until it can be executed with no possible serialization failures. It reflects the current transaction and is meaningful only for a read-only serializable transaction before the snapshot is acquired.

transaction_deferrable is session-settable but represents the current transaction; PostgreSQL restricts changes after the transaction has acquired a snapshot or performed conflicting work.

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

Operational considerations

Changing transaction_deferrable in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Changing transaction semantics as a performance experiment and silently weakening an application's consistency contract.

Letting a pooled session retain transaction-related state because checkout or rollback/reset handling is incomplete.

Changing transaction_deferrable globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: For reporting, consider a read-only transaction and an isolation choice that matches snapshot requirements; use deferrability only with read-only serializable work.

OLTP: Choose transaction_deferrable for correctness semantics first. Keep the common OLTP path explicit, then override only transactions whose consistency contract justifies different blocking or retry behavior.

SMALL: Do not change transaction_deferrable as a generic speed tweak. Higher isolation or long snapshots can amplify contention and vacuum pressure on a small node.

Version history 2
  1. PG 9.5 → 9.6changed
  2. PG 9.0 → 9.1added

Related entries

Further reading

Definition snapshot: english-manuals:ba67f0bb9dd31b51b4df16b7196… · English manual source