“You never actually own a project, you merely look after it for the next generation.”
— with apologies to Patek Phillippe.

In early March 2026, Dan Blanchard published chardet 7.0.0. The package metadata was familiar — same name on PyPI, same import path, same public API. The license was not. Versions 1.1 through 6.x had shipped

PostgreSQL 19 widens multixact members to 64 bits, retiring one of the more interesting failure modes the database can produce in production. The members-space wraparound on the multixact SLRU was a genuine outage class — Metronome ate four of them in a single migration last May — and it is gone in 19. Good. Onward.

The obvious next question,

These three parameters together set the pace of autovacuum: how often it considers running, how hard it works while running, and how long it pauses to keep from monopolizing your I/O. Like the analyze pair, they are best understood as a unit.

Unsurprisingly, PGX is involved in a lot of database emergency responses. Every emergency is different, but there are some basic rules that everyone should follow for any emergency reponse.

–

• Wind your watch.

No one has a watch that winds anymore, but the point is: take a deep breath. Give yourself a minute, or two,

PostgreSQL 19 widens MultiXactOffset to 64 bits. The ceiling that has periodically taken down high-concurrency, FK-heavy clusters is gone — not raised, eliminated. If you have ever been paged at 3 a.m. because your monitoring noticed pg_multixact/members/ filling up faster than autovacuum could reclaim it, this is for you.

If your engineers have told you that you need a data lake, you should be a little suspicious. Most organizations that build data lakes don’t need them, and a substantial fraction of the ones that do build them end up with what the industry — without any irony — calls a “data swamp.” So before we get to what a

This parameter is the multixact equivalent of autovacuum_freeze_max_age. The mechanism is parallel; the underlying object being protected is not the transaction ID space but the MultiXact ID space, which most PostgreSQL users have never had to think about and the rest learned about during an outage. So before the parameter, the multixact tour.

Second in a series of dispassionate tours of managed PostgreSQL services. The first covered Amazon RDS for PostgreSQL. Aurora sits one tab over in the same AWS console and is architecturally unlike anything else on the list.

autovacuum_max_workers sets the maximum number of autovacuum worker processes that may run simultaneously. Default is 3. Context is postmaster, so changing it requires a restart. The launcher process is separate and not counted against this number.

This is the parameter that gets raised from 3 to 10 by someone who has decided autovacuum is too slow, after which

Logical replication and physical standbys did not get along, for a long time. You could have one or the other surviving a failover, but not both. PostgreSQL 17 finally shipped the machinery to fix this. PostgreSQL 18 did not really add to it. PostgreSQL 19, currently in feature freeze, adds two genuine improvements and one quality-of-life change. The honest question