Sammlung von Newsfeeds

Two conferences. Two cities. Two completely different personalities. And me, somewhere in the middle, trying to keep up. 😄

First stop Helsinki, March 24. Nordic PGDay 2026. The Finns are punctual, focused, and deadly serious about PostgreSQL. Talks start on time. Coffee is strong. Silence is not awkward, it is just how things are. I loved every minute of it.

Prevent MultiXact ID wraparound by controlling when autovacuum freezes old locks.

#​647 — May 6, 2026

Web Version

Postgres Weekly

Postgres 19 Features I'm Excited About — An opinionated run-through of some v19 highlights, including pg_plan_advice, DDL extraction functions, online REPACK/REPACK CONCURRENTLY, and observability improvements.

Tianzhou (Bytebase)

Aurora PostgreSQL separates compute and storage, replicating redo records across three Availability Zones.

At a couple recent conferences, I got to describe the process Postgres uses to select new committers/maintainers. Usually to users and developers using Postgres, but in some cases it was unclear even to experienced Postgres contributors.

The official docs are rather brief, and don’t explain various important details. Let me explain how I understand the informal process, who’s responsible for what etc.

The window for new features in PostgreSQL 19 has closed with the Commitfest PG19-Final on April 9th. 182 patches were committed in this commitfest alone (plus more in the preceding ones). No new features are being accepted for PostgreSQL 20 yet, the git branches for 19 and 20 will likely be branched off in June. Currently the focus of the PostgreSQL community is on stabilizing PostgreSQL 19 so it is ready for release at the end of summer. If everything goes well, it will be released in September 2026.

Gülçin Yıldırım Jelinek organized the Prague PostgreSQL Meetup on 27 April, 2026 Artjoms Iskovs and Andreas Scherbaum presented at the Meetup.

Cornelia Biacsics organized the PostgreSQL User Group Vienna Meetup #2 on 28th April, 2026. Bernd Reiß and Sahil Sharma spoke at the event.

Raising autovacuum_max_workers above 3 won't speed up vacuum unless you also increase autovacuum_vacuum_cost_limit—the I/O budget is divided among workers, not…

The recent archival of pgBackRest has created an important and necessary conversation in the PostgreSQL community, not only about one project, one maintainer, or one repository, but about how we think about open-source software once it becomes part of critical enterprise infrastructure.

PostgreSQL 19 finally makes logical replication and physical standbys work together safely.

This post was originally published on the Microsoft Tech Community Blog.

Introduction

At small scale, using Postgres as a job queue is totally fine, and I’d even say it’s the right call. Fewer moving parts, one less system to manage, ACID guarantees on your jobs. What’s not to love?

PgQue's zero-mutation queue algorithm eliminates the "queue death spiral" by replacing UPDATE-and-DELETE with snapshot diffing.

PostgreSQL wraps transaction IDs every two billion transactions—autovacuum_freeze_max_age stops your database from crashing when it does.

After Part 1 and Part 2, here comes the Friday schedule! I hope that on the second day of the conference, I will have more time to attend different talks and actually stay and listen!

Autovacuum's ANALYZE threshold formula combines a fixed floor and a percentage of table size.

If you have ever run pg_ctl stop -m fast on a primary and watched it hang well past wal_sender_shutdown_timeout, you have met a bug that has been sitting in walsender.c for years. As of commit c0b24b3 on master (Fujii Masao, May 1, reported by Andres Freund via FreeBSD CI), it is fixed. PostgreSQ…

Disable autovacuum and PostgreSQL will cheerfully show you every failure mode in its playbook, from table bloat to transaction ID wraparound.

PostgreSQL 19 is an admin-and-monitoring release with 212 items: worker-managed AIO, smarter planner joins, faster diagnostics, and a C11 requirement.

PGX is stepping in to maintain pgBackRest as pgxbackup, ensuring critical fixes and PostgreSQL compatibility for the industry-standard backup tool.

There's been a kind of persistent myth regarding Postgres since I first started using it seriously over 20 years ago: "Postgres doesn't support user variables." This hasn't really been true since version 8.0 way back in 2005. Part of this stems from the fact it doesn't do things the same way as other common database engines.Why don't we spend a little time exploring the functionality that time forgot?