recovery_min_apply_delay makes a standby late on purpose. For the length of the delay there is a running, queryable copy of your database on which the DELETE without a WHERE clause has not happened yet. That is the whole feature, and it is a good one. The problem is that almost everyone who sets it believes the next step is “promote

recovery_init_sync_method decides how PostgreSQL does something most people do not know it does: after a crash, before it replays a single WAL record, it opens every file in the data directory and calls fsync() on it. The parameter chooses the technique. It does not offer a way out of the job, and the job is where a surprising share of

recovery_end_command is the only hook in postgresql.conf that fires exactly once, at the moment a server stops being a restore or a replica and becomes a primary. It is a shell command. The default is empty, and empty is also my recommendation; what earns the parameter a post is what the server is doing while your command runs, and what

Errata for the cpu_index_tuple_cost, cpu_operator_cost, and cpu_tuple_cost post (2026-06-01): that post says the 4.0 default assumes a spinning disk on which a seek-and-read runs about four sequential reads. That is the folk explanation, and it is wrong. On a spinning disk a random read runs more like forty sequential reads; the documentation explained 4.0 as that ratio discounted

quote_all_identifiers is half of a pg_dump option. The other half is the --quote-all-identifiers command-line switch, and the reason the feature comes in two pieces is that a dump file is written by two different programs, each with its own opinion about which words are keywords.

Default off, context user, so any session can turn it on, and

Errata for hot_standby_feedback (2026-07-31): that post says the primary goes back to its normal vacuum schedule as soon as the standby disconnects, and tells you to watch backend_xmin in pg_stat_replication. Both are true only for a standby with no slot. When the standby streams through a slot, the reported xmin is stored in the slot, survives the disconnect, and

Sooner or later, someone on the team reads about write skew. It is an unsettling read: two transactions, each correct on its own, each looking at data the other is about to change, both committing, and the database ending up in a state that no ordering of the two could have produced. READ COMMITTED allows it. REPEATABLE READ allows it.

primary_conninfo does not make a server a standby. standby.signal does that. What primary_conninfo does is tell a server that is already a standby where to ask for WAL, and outside that situation it is inert: on a primary it sits in pg_settings doing nothing, and on a server started with recovery.signal instead of standby.signal it is not even consulted; the

Both of these parameters are a call to sleep() with a GUC attached. A newly forked backend stops for the configured number of seconds so that a developer can find its PID and attach a debugger before the interesting part begins. pre_auth_delay sleeps immediately after the fork, before the backend has read a byte from the client. post_auth_delay sleeps once