Neues vom PostgreSQL Planet

PostgreSQL Person of the Week Interview with Dian Fay: I live in Michigan with my partner Trent, a cat named Bread, and a tarantula named Carmilla. I’m originally from the Florida panhandle, but I moved up here for school lo these many years ago and wound up sticking around – it’s nice having seasons. My mother taught me how to type on her old Selectric when I was six or seven (my handwriting never recovered), and my father taught me BASIC when I was eight by copying code listings out of his Sky & Telescope magazines. In other words, I never stood a chance.

PostgreSQL 19 changes this week new system view pg_dsm_registry_allocations the LSN output format is now uniformly set to %X/%08X this also affects the pg_lsn datatype, with e.g. SELECT '0/0'::pg_lsn returning 0/00000000 (in PosgreSQL 18 and earlier: 0/0 ). the CHECKPOINT command now accepts the following options: FLUSH_UNLOGGED [ boolean ] MODE { FAST | SPREAD } new libpq connection parameter servicefile added PostgreSQL 18 changes this week

PostgreSQL 18 beta2 is will likely be released on July 17th (Thursday): 18beta2 next week .

The cooperative company DALIBO is celebrating its 20th anniversary today, giving me an opportunity to reflect on the reasons behind the success of this collective adventure.

PUG Stuttgart

PUG Stuttgart happened on June, 26th - hosted by Aleshkova Daria

At my day job, we use row-level security extensively. Several different roles interact with Postgres through the same GraphQL API; each role has its own grants and policies on tables; whether a role can see record X in table Y can depend on its access to record A in table B, so these policies aren't merely a function of the contents of the candidate row itself. There's more complexity than that, even, but no need to get into it.

Two tables, then.

Vibhor Kumar and Marc Linster; last updated July 10 2025

Progress on ABI Compliance Reporting with BuildFarm

When implementing an optimization for derived clause lookup myself, Amit Langote and David Rowley argued about the initial size of hash table (which would hold the clauses). See some discussions around this email on pgsql-hackers.

Data is a key part of any mission-critical application. Losing it can lead to serious issues, such as financial loss or harm to a business’s reputation. A common way to protect against data loss is by taking regular backups, either manually or automatically. However, as data grows, backups can become large and take longer to complete. If these backups are not managed properly or tested often, a sudden system crash could result in permanent data loss.

In Part 1 of this series, we discussed what active-active databases are and identified some “good” reasons for considering them, primarily centered around extreme high availability and critical write availability during regional outages. Now, let’s turn our attention to the less compelling justifications and the substantial challenges that come with implementing such a setup.

Last week I posted about how we often don’t pick the optimal plan. I got asked about difficulties when trying to reproduce my results, so I’ll address that first (I forgot to mention a couple details). I also got questions about how to best spot this issue, and ways to mitigate this. I’ll discuss that too, although I don’t have any great solutions, but I’ll briefly discuss a couple possible planner/executor improvements that might allow handling this better.

PostgreSQL Person of the Week Interview with Josef Machytka: I was born in Czechia and lived most of my life there. However, for the last 12 years, my family and I have been calling Berlin, Germany, our home. It is an open-minded place that gives people a lot of freedom, we like it here very much.

PostgreSQL 19 development is now officially under way, so from now on any new features will be committed to that version. Any significant PostgreSQL 18 changes (e.g. reversions or substantial changes to already committed features) will be noted here separately (there were none this week).

PostgreSQL 19 changes this week

The first round of new PostgreSQL 19 features is here:

A flame graph is a graphical representation that helps to quickly understand where a program spends most of its processing time. These graphs are based on sampled information collected by a profiler while the observed software is running. At regular intervals, the profiler captures and stores the current call stack. A flame graph is then generated from this data to provide a visual representation of the functions in which the software spends most of its processing time. This is useful for understanding the characteristics of a program and for improving its performance.

We are excited to announce the schedule for PGDay UK 2025 has been published. We've got an exciting line up for talks over a range of topics. There will be something for everyone attending.

Take a look at what we have going on: https://pgday.uk/events/pgdayuk2025/schedule/

We'd like to extend our gratitude to the whole CFP team, who did an amazing job selecting the talks to make up the schedule.

A round up of the fifth PGConf.be

The shared presentations are online, as are a couple of recordings and turtle-loading have-a-cup-of-tea locally stored photos.

pgroll 0.14 is released with several new subcommands and better control over how version schema are created.

Recently, we worked with a client who was manually backing up their 800GB PostgreSQL database using pg_dump, which was growing rapidly and had backups stored on the same server as the database itself. This setup had several critical issues:

Having attended PGConf.DE'2025 and discussed the practice of using Postgres on large databases there, I was surprised to regularly hear the opinion that query planning time is a significant issue. As a developer, it was surprising to learn that this factor can, for example, slow down the decision to move to a partitioned schema, which seems like a logical step once the number of records in a table exceeds 100 million. Well, let's figure it out.

Introduction

Over the last decade, when working on databases where UUID Version 41 was picked as the primary key data type, these databases usually have bad performance and excessive IO.

UUID is a native data type that can be stored as binary data, with various versions outlined in the RFC. Version 4 is mostly random bits, obfuscating information like when the value was created, or where it was generated.