Sammlung von Newsfeeds
Zhang Chen: Extreme Rescue: PostgreSQL Full-File Ransomware Recovery at Epic Difficulty
Ahsan Hadi: Introducing pg-healthcheck: PostgreSQL Health Diagnostics
After more than 20 years working with PostgreSQL, I keep seeing the same problems surface at the worst possible times - bloat that sneaks up on you, replication slots quietly holding back WAL, transaction ID wraparound that nobody caught in time, backups that silently stopped working weeks ago. There are also data and catalog corruption issues like TOAST table corruption or a mismatch between heap state and VM state causing problems with vacuum operations. What I always wanted was a single tool I could point at any PostgreSQL instance and get a clear, actionable picture of its health.
Dimitri Fontaine: pgcopydb v0.18
Hot off the press: pgcopydb v0.18 is out!
It’s the biggest release the project has had — 88 commits since v0.17, which shipped in August 2024. I took a break from my Open Source responsibilities for a while, because I was lacking employer support to make it happen.
warda bibi: Inside a PostgreSQL Checkpointer Bug: A Production Postmortem
One of our client’s PostgreSQL 16.8 production databases started logging what looked like a memory error:
ERROR: invalid memory alloc request sizeThe error immediately pointed toward two likely suspects:
Christophe Pettus: All Your GUCs in a Row: enable_material and enable_memoize
Zhang Chen: The PostgreSQL Feature That Makes Data Recovery Painful
Stefanie Janine Stölting: pgsql_tweaks Version 1.0.5 Released
Postgres in Production Special Series: Configuring pg_stat_statements to Reduce Deallocations (Part 5)
In Part 5 of this special Postgres in Production deep dive series, Ryan Booz turns to configuration. There are only a handful of settings that control how pg_stat_statements behaves, but they decide how much data you keep and how much you lose. This episode covers how to see when you’re losing data through deallocations, what each setting actually does, and the changes (in settings and in your application) that reduce data loss over time.
Laurenz Albe: Too many tables are bad for you
© Laurenz Albe 2026 (see here for more background)
Recently, I helped a customer investigate database problems. It turned out that these problems could be traced back to too many tables in the database. Since this may come as a surprise to many users, I thought it worth the while to write about it.
The problems that the customer observedThere were two problems that sounded like they might or might not be related to each other:
Peter Eisentraut: Waiting for SQL:202y: Stockholm (BMA) meeting report
The most recent meeting of ISO/IEC JTC1 SC32 WG3 “Database Languages” took place from the 15th to the 19th of June 2026 in Stockholm. “WG3”, as we call it, works on standardizing the database languages SQL and GQL. In that meeting, a number of proposals that are of interest to SQL and PostgreSQL were accepted, which I want to report about here.
Christophe Pettus: All Your GUCs in a Row: enable_indexonlyscan
Laurenz Albe: Impressions from the Swiss PGDay(s) 2026
Having written about the Swiss PGDay in 2024, I need not repeat all I said back then. Nonetheless, I'd like to share my impressions from the Swiss PGDay 2026 with you.
Richard Yen: Disaster Recovery is a Process, Not a Tool (Part 2)
In the previous post, I tried to lay out the framing half of this material: what actually counts as a disaster, why preparation and prevention aren’t the same as recovery, and how RPO and RTO end up being conversations with leadership rather than numbers an infrastructure team gets to declare on its own.
Cornelia Biacsics: Contributions for week 25
On June 23 2026, the London PostgreSQL Meetup Group met. Organized by:
- Valeria Kaplan
- Chris Ellis
- Alastair Turner
- Michael Christofides
Speakers:
Christophe Pettus: All Your GUCs in a Row: enable_incremental_sort
Radim Marek: Same rows, different SUM
Everyone knows not to store money as a double precision. One can hope. The rule is so well drilled that it has stopped being interesting, and it is also not where the trouble usually starts. The float is already in the schema before anyone weighs in on it: a measurement column someone later sums for a report, telemetry that drifts into a finance dashboard, a third-party feed ingested as double precision because that is how it arrived.

