PostgreSQL sorts its problems by severity. An ERROR aborts the current statement and rolls back the transaction, but the session lives on; you issue a ROLLBACK and keep working. A FATAL ends the session, dropping that one connection while the server runs on. A PANIC takes the whole server down. In normal operation the line between “your statement failed” and

An event trigger fires on database events rather than row changes: on ddl_command_start, on sql_drop, on table_rewrite, and, since PostgreSQL 17, on login. They are how you audit or veto DDL, and they come with a well-known way to shoot yourself in the foot. Write a trigger on ddl_command_start whose function raises an exception, and every

event_source is a Windows parameter, which means that for most of the people reading this it does exactly nothing. If you run PostgreSQL on Linux, or on a managed service, there is no Windows Event Log for it to talk to, and this string sits at its default forever. What follows is for the Windows minority, and it comes down

escape_string_warning has been on by default for about twenty years, and on a modern PostgreSQL configured normally it will never once speak to you. That is not a malfunction. The condition it warns about stopped being the default in 2011.

Default on, context user. What it watches for is narrow: a backslash inside an ordinary '...' string

enable_tidscan is the enable_* knob you will almost certainly never set, and for once that is not a warning, just a fact about how TID scans happen. You do not stumble into one the way you stumble into a sequential scan or a sort. A TID scan appears only when you have explicitly written a qualification on ctid, so

Reaching for enable_sort = off because a query has a slow sort in it is usually aiming at the wrong target. When a sort is slow, it is generally because it spilled to disk, which is a work_mem problem. When a sort genuinely should not be there at all, the fix is an index. enable_sort changes neither of those, and

enable_seqscan does not disable sequential scans. It cannot, and it was never meant to. The documentation says as much: sequential scans cannot be suppressed entirely, because sometimes reading the whole table is the only way to answer the query. What off actually does is tell the planner to avoid a sequential scan when it has any other option. That is

You are rarely the only thing writing your SQL. Your ORM writes some of it, your nested views write more, and sooner or later one of them joins a table to itself on its own primary key. That join returns exactly the rows it started with. enable_self_join_elimination is the PostgreSQL 18 optimization that notices and deletes it.

Default on

Here is a log line from a PostgreSQL 14 database that PostgreSQL 14 cannot produce:

1
ERROR: role "postgres" cannot SET ROLE to "rds_superuser"

The context: Amazon RDS, a major-version upgrade done through logical replication, with a reverse subscription pointed back at the old primary so we could fall back if the cutover went badly. Standard

enable_presorted_aggregate is on, it has been on since PostgreSQL 16 introduced it, and the single most useful thing you will ever do with it is turn it off for exactly one query.

Default on, context user: settable per session, per role, per database, or inline in a single transaction. That last option is the entire recommendation,