Neues vom PostgreSQL Planet

In 2023-2024, after incidents that multiple customers of PostgresAI experienced, when production nodes were down because of LWLock:LockManager contention, we studied it in synthetic environments.

At that time, we managed to reproduce the issue only on large machines – ~100 or more vCPUs.

With PG18 release, this question started to bother me again: can we experience LWLock:LockManager on smaller machines?

The Sinking of the RMS Titanic in 1912 has shocked and entertained for over a century.  I will admit to being shocked to find a GitHub Repo with a CSV formatted file with the passenger list. This file is an interesting glimpse into the lives of the folks who sailed on the ill fated ship so long ago. And interesting datasets are always good for examples. I had been looking for a project to show off what I call 'Lifting and Shifting' but others call ETL. 

After 2-003, @ninjouz asked on X:

If fast-path locks are stored separately, how do other backends actually check for locks?

This year, CYBERTEC is celebrating 25 years since its founding in 2000 by our CEO Hans-Jürgen Schönig. In light of this, we have decided to hold an interview with the man himself to get some insights into how the company started and where it might be going. In addition to this, Hans-Jürgen made some interesting points about leading a business and the importance and future of PostgreSQL as a whole,  so buckle up and prepare for some glimpses into the thought processes of an accomplished entrepreneur in our 2-part blog posting.

As we discussed, Lock Manager manages heavyweight locks – various kinds of them (various modes, various levels of granularity). These locks are released only at the end of the transaction.

In the most trivial case, when you run a SELECT on a table, this table is locked with AccessShareLock. And not only the table, but all its indexes, which happens during planning time (always happens unless you use prepared statements). This is to protect against concurrent DROP. All of these are released only when the transaction ends.

The PostgreSQL 18 Press Kit contributors team is formed by translators from different countries covering an important set of languages. Here we have the list for the PostgreSQL 18 release. More information can be found here:

PostgreSQL 19 changes this week GROUP BY ALL syntax added IGNORE NULLS / RESPECT NULLS option added to window functions PostgreSQL 19 articles Waiting for PostgreSQL 19 – Add GROUP BY ALL. (2025-10-02) - Hubert 'depesz' Lubaczewski PostgreSQL 18 articles The journey to virtual generated columns (2025-10-02) - Peter Eisentraut / EnterpriseDB Pipelining in psql (PostgreSQL 18) (2025-10-01) - Daniel Vérité Going down the rabbit hole of Postgres 18 features (2025-09-29) - Tudor Golubenco / xata PostgreSQL 18 and beyond: From AIO to Direct IO?

This CNPG Recipe explores the latest enhancements to CloudNativePG’s software supply chain and image management. Learn how our new, fully controlled build process—complete with Snyk scanning, image signing, and SBOMs—delivers smaller, more secure PostgreSQL images. We also detail how to leverage the newly streamlined image catalogs for simplified, declarative cluster management and safer fleet-wide upgrades in Kubernetes.

This is the third post about running Jepsen against CloudNativePG. Earlier posts:

Let's talk about relation-level locks and various confusions, surprises and what is worth to remember in practice.

The key page in Postgres docs describing relation-level locks is here: https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-TABLES

Many experienced DBAs joke that you can boil down the entire job to a single rule of thumb: Don’t lose your data. It’s simple, memorable, and absolutely true – albeit a little oversimplified.

Mark Porter’s Cultural Hint “The Onion of our Requirements” conveys the same idea with a lot more accuracy:

To warm up, let's talk about lightweight and heavyweight locks (or "regular locks" or just "locks").

I'm using these materials:

Moving a Postgres database isn’t a small task. Typically for Postgres users this is one of the biggest projects you’ll undertake. If you’re migrating for a new Postgres major version or moving to an entirely new platform or host, you have a couple options:

PostgreSQL handles large JSON payloads reasonably well until you start updating or deleting them frequently. Once payloads cross the 8 KB TOAST threshold and churn becomes high, autovacuum can dominate your I/O budget and cause other issues. I have been exploring the idea of moving older JSON data (read: cold data) to Parquet on S3 while keeping recent data hot in PostgreSQL daily partitions, then simply dropping those partitions instead of running expensive DELETE operations and subsequent vacuum cycles.

PostgreSQL is a very versatile database. It has countless ways of bringing different functionalities to an already very sophisticated piece of software. Today, I’m going to show you how to use Rust and pgrx to bring etcd into your PostgreSQL database through a nice little interface called Foreign Data Wrappers.

(an image representing rust, etcd and postgres working together. Drawn by Jeremy Sztavinovszki)

Our platform team has a regular meeting where we often use ops issues as a springboard to dig into Postgres internals. Great meeting today – we ended up talking about the internal architecture of Postgres replication. Sharing a few high-quality links from our discussion:

Alexander Kukushkin’s conference talk earlier this year, which includes a great explanation of how replication works

On 29th of September 2025, Tom Lane committed patch: Add GROUP BY ALL.   GROUP BY ALL is a form of GROUP BY that adds any TargetExpr that does not contain an aggregate or window function into the groupClause of the query, making it exactly equivalent to specifying those same expressions in an explicit GROUP … Continue reading "Waiting for PostgreSQL 19 – Add GROUP BY ALL."

the psql client version 18 comes with pipelining, which can speed up client-server communication. In this post, let's see how it works and how much can be gained in query throughput with a simple example.

 Learning Structured Query Language can be frustrating when double-checking that what you wanted to have done is actually what was done. PostgreSQL 18 has 'OLD and NEW support for RETURNING clauses in INSERT, UPDATE, DELETE, and MERGE commands'. Now you can get instant feedback. 

The addition of the RETURNING clause in the previous version made MERGE much easier to use. Now it makes other commands easier.

To demonstrate, let's create a table with one column that is designated as a unique, primary key integer and insert a value.

© Laurenz Albe 2025

If you are reading this hoping that PostgreSQL finally got UPDATE ... LIMIT like MySQL, I have to disappoint you. The LIMIT clause is not yet supported for DML statements in PostgreSQL. If you want to UPDATE only a limited number of rows, you have to use workarounds. This article will describe how to do this and how to avoid the pitfalls and race condition you may encounter. Note that most of the following also applies to DELETE ... LIMIT!