CRIT Template

crit.yml is for transactional workloads with increased consistency and audit requirements. It forces data checksums and Patroni strict synchronous mode. It also adds connection logging and adjusts selected WAL, timeout, and parallel-query parameters.

The template increases write latency and may block writes when no synchronous replica is available. Before use, confirm consistency objectives, failure domains, client commit settings, and availability requirements.

Also evaluate node_tune: crit. You can select host tuning and database parameters independently.

Usage

pg-critical:
  hosts:
    10.10.10.11: { pg_seq: 1, pg_role: primary }
    10.10.10.12: { pg_seq: 2, pg_role: replica }
    10.10.10.13: { pg_seq: 3, pg_role: replica }
  vars:
    pg_cluster: pg-critical
    pg_conf: crit.yml
    node_tune: crit

A three-node topology lets the cluster select another synchronous replica after one node fails. Continued write availability depends on the remaining node state, DCS, network, and synchronous-replica selection. Test failures on the target topology.

Strict Synchronous Replication

CRIT does not derive synchronous mode from pg_rpo. It always enables these settings:

synchronous_mode: true
synchronous_mode_strict: true

synchronous_mode_strict prevents Patroni from switching to asynchronous replication when no synchronous replica is available. The primary then blocks writes that require synchronous acknowledgment.

The mode targets preservation of acknowledged transactions when:

• the session has not lowered synchronous_commit to local, off, or another asynchronous level;
• a synchronous replica acknowledges WAL during commit;
• failover selects only an eligible node containing the required WAL.

Validate RPO against client parameters, replication state, and the failure model. The template name alone does not establish RPO.

To require acknowledgment from multiple synchronous replicas, change Patroni dynamic configuration:

pg edit-config pg-critical

synchronous_node_count: 2

A higher synchronous-replica count imposes stricter conditions for accepting writes.

Data Checksums

CRIT initialization always includes:

initdb:
  - data-checksums

This overrides a disabled pg_checksum setting and enables page checksums for a new cluster. Checksums detect page damage after a write. They do not detect logical errors or every memory error.

Connection and Query Logging

CRIT logs DDL, statements taking longer than 100 ms, and disconnection events:

log_statement: ddl
log_min_duration_statement: 100
log_disconnections: 'on'

PostgreSQL 18 and later use:

log_connections: 'receipt,authentication,authorization'

Earlier versions use log_connections: on. These records support connection auditing but do not provide fine-grained SQL audit logs. Enable pgaudit separately to record object reads and writes, roles, or statement classes.

CRIT sets track_activity_query_size to 32 KiB to retain longer active-query text. Logs may contain SQL and business data. Restrict access and set a suitable retention period.

Watchdog

CRIT changes Patroni watchdog from disabled to automatic:

watchdog:
  mode: automatic
  device: /dev/watchdog

automatic activates only when the system has a usable watchdog device. If fencing must be mandatory, verify hardware, virtualization support, and device permissions before you explicitly set required. An incorrect configuration can prevent primary startup or interrupt failover.

Key Parameter Differences

CRIT also disables parallel gather for individual queries and adjusts parallel costs, autovacuum, WAL, and statistics parameters. The release file roles/pgsql/templates/crit.yml defines the active values.

Preloaded Extensions

CRIT generates shared_preload_libraries from pg_libs. The role default is:

pg_libs: 'pg_stat_statements, auto_explain'

Selecting crit.yml alone does not load passwordcheck. If you need password-complexity checks, configure it explicitly:

pg_libs: '$libdir/passwordcheck, pg_stat_statements, auto_explain'

ha/safe includes this override. To use pgaudit, also add it to pg_libs and configure the audit scope:

pg_libs: '$libdir/passwordcheck, pg_stat_statements, auto_explain, pgaudit'
pg_parameters:
  pgaudit.log: 'ddl, role, write'

Performance and Availability Impact

• Synchronous commit waits for a synchronous replica; write latency includes at least replica network and WAL durability time.
• Strict synchronous mode blocks writes when no synchronous replica is available.
• Disabling parallel gather can reduce throughput for large queries, but also reduces resource variability from parallel execution.
• More detailed logging and statistics consume additional I/O, CPU, and storage.
• A shorter idle-transaction timeout may terminate application sessions that hold a transaction open without executing statements.

The impact depends on hardware, network, queries, and client behavior. Test the actual workload. Do not rely on a fixed latency or throughput percentage.

Launch Checklist

• Deploy at least one usable synchronous replica and verify write behavior during node failure
• Check whether applications change synchronous_commit
• Select watchdog automatic or required according to availability requirements
• Verify collection, access control, and retention for connection logs
• Configure pg_libs and extension parameters explicitly when password checks or SQL auditing are required
• Test write latency, throughput, and idle-transaction timeouts with the production workload
• Exercise primary, synchronous-replica, DCS, and network-partition failures

Related Documentation

• Security Model: where CRIT fits in the overall hardening path
• Data Security: boundaries of synchronous replication, checksums, and auditing
• ha/safe Configuration: three-node hardening example that includes CRIT
• Sync Standby: synchronous replication configuration
• Quorum Commit: synchronous replica count
• OLTP Template: general transaction template