These are the oldest logging parameters PostgreSQL still ships, and the output looks it. Each is a boolean, off by default, superuser context, and each makes the backend call getrusage() before and after one stage of running a statement and write the difference to the log at LOG level. log_parser_stats covers the parser, parse analysis, and the rewriter (three blocks

These two parameters answer the same question about the same process: what is the startup process doing, and why is it not done? The startup process is the backend that replays WAL. On a primary it exists only during crash recovery, and while it exists nothing else can connect; a client gets FATAL: the database system is not yet accepting

log_lock_waits is the cheapest lock-contention detector PostgreSQL ships, and through version 18 it is off by default. Turn it on. PostgreSQL 19 will do it for you.

The mechanism is borrowed rather than built. When a backend has to sleep on a heavyweight lock (a row, a relation, a transaction ID, an advisory lock), it arms a timer for

log_replication_commands is log_statement = all for walsenders, with the one difference that you should turn it on.

A replication connection (replication=1 for physical, replication=database for logical) speaks a small language of its own: IDENTIFY_SYSTEM, CREATE_REPLICATION_SLOT, START_REPLICATION, BASE_BACKUP, DROP_REPLICATION_SLOT, and a few others. log_statement never sees them. This parameter does, and writes each one

Last time ended with log_min_duration_statement set to a threshold you would actually investigate. The cost of that threshold is that everything below it is invisible, and the queries below it are frequently the story: one query that runs for a minute is a problem you can see, but twenty million queries at a millisecond each are five and a half

Every other statement-logging parameter in this cluster decides whether a query goes into the log. These two decide whether your users’ data goes with it.

Under the extended query protocol the statement text arrives with $1, $2 placeholders and the values arrive separately, in the Bind message; those values are the bind parameters. When log_statement, log_min_duration_statement

Every message on its way to the server log passes three gates: whether it gets in at all, whether the SQL that provoked it rides along, and how many of its fields get printed. One parameter per gate. All three control only the log’s copy of a message; what the client sees is client_min_messages’s business, and the two streams

A log line has two parts: the message, which PostgreSQL decides, and everything in front of it, which you do. log_line_prefix is the join key. Every fact that lets you connect a line to a session, a transaction, a client, or a moment in another system’s logs has to be in the prefix, because the message itself doesn’t carry it.

These three decide when the logging collector closes one file and opens another, and they only make sense together with log_filename, because the collector never deletes anything: rotation is just “compute a name from the pattern and open it.” What happens next depends entirely on whether that name is new, and the three parameters here control the timing and

All three of these do nothing unless logging_collector is on; they describe the files the collector writes. Where, what they’re called, and who can read them. The defaults for all three are fine for a laptop and wrong for a server, and the reasons are more mechanical than the documentation lets on.