hot_standby_feedback does not eliminate a problem. It moves one, from the standby to the primary, and whether that is a good trade is the entire question.

The problem is recovery conflicts that cancel long-running queries on a standby. The standby is replaying the primary’s changes while also answering read queries, and when the primary vacuums away dead row versions,

hot_standby is the switch that decides whether a standby server is a spare you can only fail over to or a replica you can also read from. It has been set to the second of those by default since PostgreSQL 10, which is why, for most people running replication today, it is a switch already in the position they want

hba_file is a pointer, not a policy. It tells the server where to find pg_hba.conf, the file that actually decides who may connect, from where, as whom, and by what authentication method. About those decisions hba_file has nothing to say. Its entire job is the address.

It is a string, its context is postmaster so it is fixed

Sorts and hashes do not have the same relationship with memory, and this parameter exists because PostgreSQL spent most of its history pretending they did.

hash_mem_multiplier is a floating-point value, its default is 2.0, its context is user, and it ranges from 1.0 to 1000. What it does is simple to state: hash-based operations are allowed to use

gss_accept_delegation is a boolean, it defaults to off, and its context is sighup. It controls whether your PostgreSQL server will accept Kerberos credentials that a client hands it, and the reason it defaults to off is that accepting them means the server can then turn around and act as that user against other systems. This is one of

The name is misleading twice over. It has nothing to do with fuzzy matching, the trigram-similarity, close-enough-spelling sense that people reach for pg_trgm to get. And it is not really a search limit either. The fuzziness is in the size of the result set, and what this parameter actually does is instruct PostgreSQL to give you fewer rows than match

Seven parameters, one feature, and a reasonable goal of never using any of them.

geqo, geqo_threshold, geqo_effort, geqo_pool_size, geqo_generations, geqo_selection_bias, and geqo_seed all configure the Genetic Query Optimizer, an alternative join-order search that PostgreSQL falls back to when a query has too many relations for the regular planner to handle exhaustively. All seven

full_page_writes is a boolean, it defaults to on, and its context is sighup, set in postgresql.conf or on the command line. It is the reason crash recovery works at all, and it is also the reason your WAL graph has a sawtooth in it.

fsync is a boolean, it defaults to on, and its context is sighup, so it can be changed with a configuration reload rather than a restart. It is also the most dangerous setting in postgresql.conf. Most of the parameters in this series, set wrong, cost you a bad plan or some wasted memory. This one, set wrong,

Almost nobody writes the query shape this parameter governs:

1
SELECT * FROM x, y, (SELECT * FROM a, b, c WHERE something) AS ss
2
WHERE somethingelse;

But you produce it constantly without meaning to. Reference a view that contains a join and the view’s definition is inserted in place of the reference, leaving the