Neues vom PostgreSQL Planet

When a PostgreSQL backend crashes, the postmaster can restart itself automatically or exit and wait for external intervention. (I consult on PostgreSQL through PGX Inc..)

SQL vs PL/pgSQL functions in PostgreSQL 16: why a SQL function is re-planned on every loop call, how to reduce plan time.

For years, installing many packages from the PostgreSQL RPM repository on RHEL and its rebuilds started with the same step: `dnf install epel-release`. PostGIS, pgBackRest, pgcli, patroni, pg_statviz, ora2pg and lots of extensions pulled at least one dependency from EPEL.

Over the last couple of weeks I removed most of those dependencies. On RHEL 8, 9 and 10, the GIS stack, the most popular extensions and almost all of our Python tools now install from the PGDG repositories and the OS repositories (BaseOS, AppStream and CRB) alone.

As promised during the session, I'm sharing the slides from the "Fostering Inclusivity with the PostgreSQL Europe Diversity Committee" presentation at the New PostgreSQL Community Members - Summit at PostgreSQL Conference Europe (PGConf.EU) 2026.

Most teams I work with have a backup dashboard, and most days it is green. The job ran; it finished; nothing failed. That green tick feels like safety, and it is the reason nobody thinks about backups again until the day they need one. Then something breaks, someone asks how long it will take to get the database back, and the room goes quiet. Nobody knows. The backups have been running for a year, and nobody has ever brought one back. 

Most database proxies that do read/write splitting get one thing wrong: after a client writes a row and immediately reads it back from a replica, the read can return stale data.

Every commit in PolarDB ends the same way: the WAL record must reach shared storage. On the way there, the bytes move from a WAL buffer, through the shared-storage daemon, to a device.

PostgreSQL 16's `reserved_connections` reserves slots for your monitoring and backup roles when the application exhausts the pool. (I consult on PostgreSQL through PGX Inc..)

In the previous two posts you could see how to manage storage for create and drop and also to work with transactions. In this post you’ll learn how to handle TRUNCATE, which replaces the arena of a table with a new one. Doing that safely means choosing which arena to release based on how the transaction ends. This post handles the normal path, the in-place path Postgres takes for tables created in the same (sub)transaction, and the rollback cases for both.

AwideLabs Tech Column: How we took PolarDB from a promising open-source project to production-ready Awide Polar.

Every durable database change in PolarDB passes through one place before it is safe: the write-ahead log. A replica is just a machine that stores that log and replays it. But how if a cluster need a pure copy of the WAL?

Every time PostgreSQL decides whether a row is visible to your query, it asks the same question: was the transaction that wrote this row already committed when my snapshot was taken?

Protect your disk from orphaned temporary files after a backend crash. (I consult on PostgreSQL through PGX Inc..)

A first look at what CloudNativePG 1.31 will bring to PostgreSQL credentials: a DatabaseRole can now generate its own password, keep it in a Secret the operator owns, shape it with criteria and rotate it on a schedule, with PostgreSQL enforcing the lifetime through VALID UNTIL. The feature is merged but not yet released, so this recipe anticipates 1.31 and shows how to try it today on the latest development snapshot.

On 12 October, the PostgreSQL User Group Vienna met, organized by * Cornelia Biacsics * Ranjeet Kumar

Speakers:

• Mayur B.
• Radim Marek

On 13 October, the San Francisco Bay Area PostgreSQL Meetup Group met online. Christophe Pettus delivered a talk. The meetup was organized by:

PostgreSQL 15's `recursive_worktable_factor` helps you fix slow recursive CTEs by tuning a single estimate. (I consult on PostgreSQL through PGX Inc..)

PolarDB separates compute from storage. Many machines can reach the same block device. Exactly one of them may write to it. A second read-write mount corrupts data, and there is no recovery from it.

Yesterday, I spoke about pg_acm at PGConf.EU. Speaking at the biggest Postgres conference in the world is an honor in itself, and it’s not that I have a chance to present there every year, so I am incredibly thankful to the CfP committee for choosing this talk.

This talk has a long history of rejection and denial of the fact that something could be wrong with Postgres, which made me appreciate this opportunity even more.

Every major PostgreSQL upgrade I have done on a single primary came with the same conversation: how long can the application be down?  is fast, but it is still an outage, and you still have to rebuild or resync the standbys afterwards.A multi-master cluster gives you a different option. Spock is pgEdge's open-source PostgreSQL extension for multi-master logical replication, and with it every node takes writes, so you never have to upgrade a node in place. You add a brand new node on the new major version, let it join the cluster, move traffic to it, and retire the old one.

Please enjoy the slides and transcript from Tuning Postgres for Analytics at PostgreSQL Conference Europe (