Back, after recovery from PGConf.EU!

scram_iterations is not really a server setting. It is the default for a property of each password, written into the password at the moment it is set, and the server itself reads the number on only two later occasions: when someone sets another password, and when someone tries to log in as a role

row_security = off does not turn row-level security off. Nothing a plain session can set could turn row-level security off, for the obvious reason, and row_security is a plain-session setting: boolean, default on, context user, settable by any role in any session, and per role or per database with ALTER ROLE ... SET or ALTER DATABASE ... SET

restrict_nonsystem_relation_kind is a security patch that happens to be spelled like a configuration parameter. You will almost never set it. pg_dump sets it, on its own connection, as the last thing it does before opening its transaction, and the entire reason the parameter exists is so that it can. The manual gives it three sentences and never says the word

PostgreSQL has no idea where your WAL archive ends. During archive recovery it finds out the only way it can: it asks restore_command for the next segment, and the next, and the next, until the command fails. That failure is the end of the archive, by definition, whatever actually caused it. Nearly everything worth knowing about this parameter follows from

Anyone who has run PostgreSQL for long enough has read this, usually at a bad moment:

1
WARNING: terminating connection because of crash of another server process
2
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
3
 

Errata: the max_connections post told you to size the parameter as what the poolers open, “plus the replication connections,” plus a couple of dozen for humans and monitoring. Drop the replication connections from that sum. Since PostgreSQL 12, walsenders are drawn from their own pool, sized by max_wal_senders, and do not count against max_connections at all. The rest of

remove_temp_files_after_crash is a disk-space protection filed under debugging. The manual lists it in Developer Options, the section whose preamble tells you never to use any of this on a production database, and for once the warning is exactly right: the default, on, is the production setting, and the only thing the parameter lets you do is turn the protection

recursive_worktable_factor is a planner hint, and the people who committed it said so at the time. It went into PostgreSQL 15 because nobody on the thread could think of anything better, which is a more honest origin than most parameters get, and it tells you how to use it: one query at a time, after you have looked at the

Every parameter in this post answers one of three questions about a restore from a WAL archive: where should replay stop, which history should it follow to get there, and what should the server do when it arrives. Eight parameters, three questions. recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time and recovery_target_xid are five ways of answering the first. recovery_target_timeline answers