post_auth_delay

Definition PG 18 manual

The amount of time to delay when a new server process is started, after it conducts the authentication procedure. This is intended to give developers an opportunity to attach to the server process with a debugger. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the delay. This parameter cannot be changed after session start.

How it works

post_auth_delay pauses a newly created backend after authentication succeeds, giving a developer time to attach a debugger to that process. Zero disables the delay.

The backend-context value is fixed at session start. Authentication has completed, so the session and server resources are already allocated while it sleeps.

This intentionally increases connection latency and can consume backend slots under connection storms. It is not a throttling, security, or connection-pooling control. Its backend context fixes the value during connection startup; an existing session cannot change it.

Operational considerations

Leaving post_auth_delay enabled after the bounded diagnostic or recovery task.

Running the experiment on the only copy of production data.

Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.

Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Workload guidance

OLAP: Long analytical runs can amplify post_auth_delay's debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.

OLTP: Do not tune production OLTP with post_auth_delay. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.

SMALL: Keep post_auth_delay at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.