listen_addresses decides which TCP sockets exist. It has nothing to say about who may use them; that is pg_hba.conf’s job, and most of the grief this parameter causes comes from confusing the two.

It is a string, a comma-separated list of host names and IP addresses, and the default is localhost. Context is postmaster, so changing

lo_compat_privileges sets large-object security back to PostgreSQL 8.4, the last release in which a large object belonged to nobody in particular and any role that could connect to the database could read it, overwrite it, or delete it. PostgreSQL 9.0 gave large objects an owner and an ACL. This parameter is the switch that pretends it didn’t.

Default off

local_preload_libraries is the preload parameter for people who aren’t allowed to use the other two. It loads shared libraries into a backend at connection time, the same as session_preload_libraries, with two differences: any role can set it, and in exchange it will only load from one directory, $libdir/plugins, which on a stock installation is empty if it exists

lock_timeout is a schema-migration safety parameter that happens to apply to every lock in the system. It caps how long a statement will wait to acquire any single heavyweight lock before giving up with ERROR: canceling statement due to lock timeout (SQLSTATE 55P03, the same code NOWAIT failures use, which is convenient for client code). Default 0, meaning

Neither of these parameters has anything to do with the krb5 authentication method, because PostgreSQL removed that method in 9.4. The krb_ prefix survives for the usual reason parameter names survive anything: renaming a GUC breaks every postgresql.conf that mentions it. What they actually configure is GSSAPI authentication, the gss method in pg_hba.conf, which in practice means Kerberos, which

PostgreSQL famously does not implement query hints. This is about 95% true, and join_collapse_limit is the other 5%: set it to 1, and the planner joins your tables in exactly the order you wrote them. This is not an exploit or an accident of implementation; it is documented, and according to Tom Lane on pgsql-hackers, it is essentially why

The jit_* family closes with the three parameters for people working on the JIT itself rather than with it. All three are booleans, all default off, all date to the original PostgreSQL 11 work, and all live in Developer Options. What makes them worth a post at all is that one of them is genuinely fun, and the other

Here is a fact about PostgreSQL that surprises even people who have been running it for years: every query against a table takes a lock on every index on that table, whether or not the query uses any of them.

This is usually harmless. The locks are AccessShareLock, the weakest lock there is; they conflict with almost nothing,

The third cluster of the jit_* family is the one that decides when JIT happens, and it is where the trouble lives. All three arrived with the subsystem in PostgreSQL 11, all three have context user, and all three are denominated in planner cost units, that dimensionless currency anchored to seq_page_cost = 1.0. When the planner finishes

Continuing through the jit_* family in logical clusters: this pair decides what JIT compiles, and you have already seen their names, because they are the “Expressions true, Deforming true” printed in every JIT block the last post showed. Both are boolean, context user, default on, part of the original PostgreSQL 11 JIT work, and filed under Developer Options,