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,

The io_* parameters we’ve covered so far describe the I/O requests: how big each one is, how many a process may have in flight. These two decide who actually performs them. I wrote about the architecture, and about what PostgreSQL 19 does to it, in AIO Grows Up; this is the parameter-level view, and it includes a

effective_io_concurrency is a request. io_max_concurrency is the grant.

New in PostgreSQL 18 as part of the asynchronous I/O subsystem, io_max_concurrency is the hard ceiling on how many I/O operations a single process can have in flight at once. Not per cluster; per process. The context is postmaster, so changing it requires a restart, and the default is -1