CVE-2026-2005, CVE-2026-2006, and CVE-2026-2007 are now patched. All three are heap buffer overflows in PostgreSQL or its bundled extensions. The pgcrypto bug — the headline one — has been sitting in the tree since approximately 2005, which means it is older than the iPhone, Twitter, and (for some of you reading) your career. Two of the three were found by

commit_delay is the one knob that tells PostgreSQL’s group commit to wait for a bigger group. The database already batches WAL flushes on its own: when one backend is flushing the WAL, others that become ready to commit queue up behind it and ride along on the same fsync. commit_delay makes the backend leading that flush pause for a

VACUUM FULL is not actually a tool you can use in production. It rewrites the entire table under ACCESS EXCLUSIVE lock, which means everything that touches that table (including the autovacuum worker that is, somewhere else in the system, probably the reason you needed VACUUM FULL in the first place) waits. On a serious table on a busy system, that

cluster_name looks like a cosmetic: a label that shows up in ps output so you can tell your three postgres instances apart. On a primary, that’s all it is. On a standby, it can quietly become the name the primary uses to decide whether synchronous replication is satisfied, which is a much bigger job for a parameter most people set

Fourth in a series of dispassionate tours of managed PostgreSQL services. Previously: RDS, Aurora, and Cloud SQL. AlloyDB is Google’s distributed-storage PostgreSQL, the closest architectural parallel on GCP to Aurora on AWS, with enough distinctive differences to be worth understanding as its own thing rather than “GCP’s Aurora.”

refint is a vintage referential-integrity workaround (committed September 10, 1997! that became pointless the day real foreign keys shipped in PostgreSQL 7.3, twenty-three years ago. It is still in the contrib tree because… well, that’s a good question. And on May 14 it shipped a stack buffer overflow plus SQL injection (CVE-2026-6637, CVSS 8.8) that lets any unprivileged

client_min_messages controls how much the server says to you: the messages that come back over the wire to your session. It is constantly confused with the parameter that controls what the server writes to its own log. Those are different concerns with different parameters, and the confusion is where most of the trouble starts.

The default is NOTICE

A genuinely useful parameter that almost nobody knows about. Added in PostgreSQL 14, off by default, fixes a specific pathology that anyone who has run analytics workloads has lived through at least once.

In Wednesday’s post on table access methods, I grouped Snowflake with Databricks and Microsoft as vendors with “bespoke storage layers underneath their Postgres-shaped products.” Elizabeth Christensen wrote in to point out that this is wrong about Snowflake, and she is right.

Snowflake Postgres is community Postgres. The storage, the heap, the table access method machinery, all of it is

client_encoding declares what character encoding the client speaks. The server uses it to convert between its own internal encoding (set at initdb time, per-database, often UTF-8) and whatever the client is sending and expecting. Default is “the server’s encoding” — that is, no conversion. Context is user, with PGCLIENTENCODING as the environment variable that libpq honors automatically, mirroring application_name