Neues vom PostgreSQL Planet

Agent memory has been in fashion ever since agents appeared: it fights hallucinations and lets an LLM base its answers and decisions on your own information. Whether it is better to query that information from tables or from a graph is often decided on faith, after reading posts on the internet, without experiments and measurements of your own.

After pg_dump and pg_restore, by default the planner statistics and the visibility map are missing. One query: 32.6 s before VACUUM ANALYZE, 23 ms after.

PostgreSQL's `restore_command` asks for WAL segments one at a time until the command fails—and that failure marks the archive's end, whether it's real or not. (I consult on PostgreSQL through PGX Inc..)

PostgreSQL's no pg_hba.conf entry for host, measured on 12 to 18 (not 15): the 'no encryption' tail, Docker's gateway address, hostssl, replication and reload.

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..)