PostgreSQL 18 shipped asynchronous I/O. The dominant flavor on Linux was io_uring; everything else fell back to a worker pool controlled by io_method=worker. Early benchmarks from pganalyze, Aiven, and Better Stack showed real wins on read-heavy workloads with large sequential scans. They also showed that the worker fallback needed careful tuning — the default worker count did not

Here is a GUC that ships with a warning label. The docs, which are normally restrained to the point of parody, state plainly that setting this parameter wrong can cause “irretrievable data loss or seriously corrupt the database system.” When the PostgreSQL docs raise their voice, listen.

allow_system_table_mods is off by default. Turning it on lets a superuser perform

If you’re going to hire a PostgreSQL consultant, hire one. That means access to the database.

I’m writing this because the “we hired you but you can’t touch the thing” conversation happens at the start of roughly one in four PGX engagements, and I would like to have something to point at instead of having the same conversation over

allow_in_place_tablespaces exists so the PostgreSQL test suite can test replication. That’s it. If you’re reading this as an operator, you will never touch it. But it’s in the alphabet, so here we are.

When off (the default), CREATE TABLESPACE requires a LOCATION that points to an existing, empty, absolute directory path. The server creates a symbolic link in $PGDATA/pg_tblspc/

Robert Haas’s pg_plan_advice patch set, proposed for PostgreSQL 19, is where the twenty-year argument from Part 2 has landed — or is trying to. It is not pg_hint_plan brought into core. It is a different thing, with different mechanics, a different scope, and a different answer to the “why is this different from Oracle-style hints” question.

The patch

We begin at allow_alter_system, which is both new and politically fraught — so let’s start with a fight.

ALTER SYSTEM was added in 9.4 as a quality-of-life improvement: set GUCs from an SQL prompt, have the values written into postgresql.auto.conf, no shell access required. It was immediately controversial among people running PostgreSQL under configuration management. If Ansible

For most of PostgreSQL’s history, the official community position on query hints has been a polite version of “no, and stop asking.”

The position isn’t subtle. The PostgreSQL wiki maintains a page titled Not Worth Doing, and “Oracle-style optimizer hints” is listed there, right above in-process embedded mode and obfuscated function source. The companion wiki page, OptimizerHintsDiscussion,

pg_plan_advice is expected to land in PostgreSQL 19. That makes this a good moment to look at query hints — what they are, what every other major database does with them, and how PostgreSQL ended up being the obvious outlier. Three parts. This is the first.

I subscribe to Medium (don’t judge), and their weekly summary pushed an article to me entitled The Postgres Revolution Is Here: Why Version 18 Changes Everything for Developers. Well, OK, that sounds relevant to my interests. Let’s check it out!

Oh.

Oh, dear.

Oh, sweet Mother of God.

The author lists 10 new incredible amazing

Sometimes, we run into a client who has port 5432 exposed to the public Internet, usually as a convenience measure to allow remote applications to access the database without having to go through an intermediate server appllication.

Do not do this.

This report of a “security issue” in PostgreSQL is alarmist, because it’s a basic brute-force attack