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

Most people first read this parameter’s value in an error message that has no TCP in it:

1
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
2
    Is the server running locally and accepting connections on that socket?

The 5432 on the end of that file name is port.

On August 25, Robert Haas opened a pgsql-hackers thread like this:

I asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed post-freeze. Results below, with a few particularly cutting remarks from the LLM edited out.

The subject line was “scary patch contest.” Six patches made the

plan_cache_mode is the override for a decision PostgreSQL makes on your behalf, from estimates alone, the sixth time a prepared statement runs. I spent eighteen minutes of your time on that decision in The Sixth Execution and will not repeat it here. The short version: a prepared statement can run with a custom plan, built for the parameter values

password_encryption was a boolean from 7.2 through 9.6, and the question it answered was whether PostgreSQL should hash a new password or store it exactly as typed. In 7.2 the default was off. That is where the name comes from, and why a parameter that has never encrypted anything is still called this. PostgreSQL 10 removed the option of

max_parallel_workers_per_gather = 2 gets you three processes. The third is the backend your client is connected to, the leader, which launches the two workers and then, instead of waiting for them, runs its own copy of the same plan. parallel_leader_participation decides whether it does that. It is a boolean, the default is on, the context is user (any