Neues vom PostgreSQL Planet

I first blogged about Transparent Data Encryption (TDE) in 2019, which was more thoroughly analyzed in a blog post in 2023. An email exchange in December 2024 summarized the most up-to-date status of this feature:

PGConf.de 2025 is the next iteration of the PostgreSQL Conference Germany. It takes place in the "Berlin Marriott Hotel" in Berlin.

https://2025.pgconf.de/

The conference will take place on May 08th & 09th, 2025.

Registration for the conference is open. The talks will be in German or English. Tickets must be purchased online.

This month, I'm excited to tell you about the returning of the PostgreSQL Hacking Workshop along with a new Patch Review Workshop organized by Paul Ramsey.Read more »

On 14th of February 2025, Nathan Bossart committed patch: Add delay time to VACUUM/ANALYZE (VERBOSE) and autovacuum logs.   Commit bb8dff9995 added this information to the pg_stat_progress_vacuum and pg_stat_progress_analyze system views. This commit adds the same information to the output of VACUUM and ANALYZE with the VERBOSE option and to the autovacuum logs.

pgsql_tweaks is a bundle of functions and views for PostgreSQL

The soucre code is available on GitLab, a mirror is hosted on GitHub.
One could install the whole package, or just copy what is needed from the source code.

The extension is also available on PGXN.

Have you ever experienced your database slowing down as the amount of data increases? If so, one important factor to consider is tuning PostgreSQL parameters to match your specific workload and requirements. 

PostgreSQL streaming replication is pretty fast. It is based on transaction log (WAL) and crash recovery mechanism. This work is something the primary must handle anyway for safe operation, so the overhead on the primary side is negligible. The only extra work is pushing WAL out onto the network in addition to disk.

Statistically, September CommitFests feature the fewest commits. Apparently, the version 18 CommitFest is an outlier. There are many accepted patches and many interesting new features to talk about.

If you missed the July CommitFest, get up to speed here: 2024-07.

PostgreSQL Europe will stop posting on Twitter/X. This includes our main accounts, and all conference accounts we operate or help to organize. . Recent changes to the platform's policies steadily transform Twitter/X into a space which we believe spreads a lot of hate and is no longer aligned with our community spirit and values.

Please connect with us on our various Social Media channels:

The first round of minor versions in 2025 was released this week: PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 Released! -  but wait! Out-of-cycle release scheduled for February 20, 2025 .

On 11st of February 2025, Nathan Bossart committed patch: Add cost-based vacuum delay time to progress views.   This commit adds the amount of time spent sleeping due to cost-based delay to the pg_stat_progress_vacuum and pg_stat_progress_analyze system views. A new configuration parameter named track_cost_delay_timing, which is off by default, controls whether this information is gathered.

I’ve been putting together a new PostgreSQL session called “Performance Monitoring for the Absolute Beginner.” There are several ways to get an understanding of how well your queries are running in PostgreSQL, but, frankly, all of them are a bit of a pain to someone coming from the land of Extended Events (ah, my one […]

The post Free PostgreSQL Performance Monitoring with pgNow appeared first on Grant Fritchey.

Have you ever faced timeline issues during PostgreSQL recovery? It can be frustrating to complete a restore only to discover during recovery that the timeline is invalid, which often results in an error message like this:

Finally I found time to get a grip on the issues I had with gohugo and get my blog operational again.

I’m taking the occasion to write about a project I care a lot as it’s strictly related with my hometown, the upcoming PGDay Napoli.

Every time I host a Postgres Meetup, I am thankful to everyone who comes. But today, I am especially thankful because so many people showed up despite the snowstorm! Staying after work to attend a meetup in these weather conditions demonstrates true dedication!

Many thanks to Steve Zelaznik for his wonderful presentations (recording will be available!), and thanks to all participants for listening, asking insightful questions, and a lively discussion afterward!

Anecdotally, this might be the most requested feature in SQL: Allow some trailing commas.

The classic example is

SELECT a, b, c, -- here FROM ...

Another one is

CREATE TABLE tab1 ( a int, b int, c int, -- here )

There might be a few other popular ones. (Please send feedback.)

© Laurenz Albe 2025

I have seen the error from the title reported often enough. If you are not familiar with the internals of PostgreSQL, the message will confuse you: what are xmin and relfrozenxid? Why is it a problem if one is before the other? So I think that it is worth the effort to write an article about the problem and what the error means. I'll also show you how to cope with the situation and fix the error.

After reading Paul's teasing article on Accessing Large Language Models with AI and testing out his code, I decided I should probably stop fighting this AI smothering. I still have a distrust of AI services but downloading an AI model and using on my own local desktop or server is nice and I can break bread with that. One use I tried is using AI to generate fake data and it did a pretty decent job.

For PostGIS Day this year I researched a little into one of my favourite topics, the history of relational databases. I feel like in general we do not pay a lot of attention to history in software development. To quote Yoda, “All his life has he looked away… to the future, to the horizon. Never his mind on where he was. Hmm? What he was doing.”

Postgres' ability to execute queries in parallel is a powerful feature that can significantly improve query performance, especially on large datasets. However, like all resources, parallel workers are finite. When there aren't enough available workers, Postgres may downgrade a parallel query to a serial (non-parallel) execution. This sounds reasonable unless the performance of the downgraded query is well beyond the required response times needed by the application.