Sammlung von Newsfeeds

In one of our earlier blogs, we explored how improper volatility settings in PL/pgSQL functions — namely using IMMUTABLE, STABLE, or VOLATILE — can lead to unexpected behavior and performance issues during migrations.

As a database consulting company, we are often faced with analytics and reporting related tasks which seem to be easy on the surface but are in reality not that trivial. The number of those seemingly simple things is longer than one might think, especially in the area of reporting

As part of the new ABI compliance reporting system for the PostgreSQL Buildfarm, there has long been a question: if a Buildfarm run fails due to an ABI incompatibility, how can it be marked successful again once the ABI break is fixed? This post explains the introduction of a new file, .abi-compliance-history, in the PostgreSQL source tree and how it is used to track ABI breaks.

When using tsearch one usually, often, creates a tsvector column to put data in, and then create index on it. But, do you really need the index? I wrote once already that you don't have to, but then a person talked with me on IRC, and pointed this section of docs: One advantage of the … Continue reading "Do you really need tsvector column?"

As I explained in my talk on PostgreSQL Conference Europe 2025, data corruption can be silently present in any PostgreSQL database and will remain undetected until we physically read corrupted data. There can be many reasons why some data blocks in tables or other objects can be damaged. Even modern storage hardware is far from being infallible. Binary backups done with pg_basebackup tool – which is very common backup strategy in PostgreSQL environment – leave these problems hidden. Because they do not check data but copy whole data files as they are.

Beyond Start and End columns with PostgreSQL range types

One of the most read articles at boringSQL is Time to Better Know The Time in PostgreSQL where we dived into the complexities of storing and handling time operations in PostgreSQL. While the article introduced the range data types, there's so much more to them. And not only for handling time ranges.

PostgreSQL received attention through the following contributions at Data Stack Conf 2025 on Oct 29, 2025:

Speaker

• Radoslav Stanoev
• Pavlo Golub
• Lætitia Avrot
• Valeria Bogatyreva
• Devrim Gündüz

PostgreSQL Booth Staff

• Devrim Gündüz
• Pavlo Golub

Gabriele Quaresima spoke at Cloud Native Bergen on Tuesday, October 28, 2025.

 I wrote a post in my MySQL blog on migrating from MySQL to PostgreSQL using DBeaver. You can pass it along to your acquaintances who want to get off the Dolphin and on the Elephant. 

Not only will DBeaver move your tables and data, but you can compare them afterwards. In the post, I outline the process in five steps. DBeaver will let you do it in four. 

From time to time I get to investigate issues with some sort of a batch process. It’s getting more and more common that such processes use very high memory limits (maintenance_work_mem and work_mem). I suppose some DBAs follow the logic that “more is better”, not realizing it can hurt the performance quite a bit.

Let me demonstrate this using an example I ran across while testing a fix for parallel builds of GIN indexes. The bug is not particularly interesting or complex, but it required a fairly high value for maintenance_work_mem (the initial report used 20GB).

PostgreSQL stores data in fixed‑size blocks (pages), normally 8 KB. When a client updates or inserts data, PostgreSQL does not immediately write those changes to disk. Instead, it loads the affected page into shared memory (shared buffers), makes the modification there, and marks the page as dirty. A “dirty page” means the version of that page in memory is newer than the on‑disk copy.

In #PostgresMarathon 2-009 and #PostgresMarathon 2-010, we explored why execution 6 causes a lock explosion when building a generic plan for partitioned tables — the planner must lock all 52 relations because it can't prune without parameter values.

Today we'll test what actually happens with different plan_cache_mode settings.

How-to guide for installing PostgreSQL version 18 on Ubuntu, after a fresh installation of version 25.10 (Questing Quokka).

In #PostgresMarathon 2-009, we focused on Lock Manager's behavior when dealing with prepared statements and partitioned tables.

And observed a lock explosion in our simple synthetic example: from 8 locks (custom plans) during first 5 calls, to 52 locks (building generic plan) in the 6th call, to 13 locks (using cached generic plan) in the 7th and subsequent calls. We left with questions:

On 28th of October 2025, Nathan Bossart committed patch: Add psql PROMPT variable for search_path.   The new %S substitution shows the current value of search_path. Note that this only works when connected to Postgres v18 or newer, since search_path was first marked as GUC_REPORT in commit 28a1121fd9. On older versions that don't report search_path, … Continue reading "Waiting for PostgreSQL 19 – Add psql PROMPT variable for search_path."

PostgreSQL Conference Europe 2025 in Riga has officially come to an end — and what remains are the impressions, emotions, moments, and the incredible vibe that remind me why we do what we do.

I met so many inspiring people, had conversations with some of my role models, and wore many hats throughout the conference.

In #PostgresMarathon 2-008, we discovered that prepared statements can dramatically reduce LWLock:LockManager contention by switching from planner locks (which lock everything) to executor locks (which lock only what's actually used). Starting with execution 7, we saw locks drop from 6 (table + 5 indexes) to just 1 (table only).

There we tested only a simple, unpartitioned table. What happens if the table is partitioned?

For this second entry into our blog feature to celebrate 25 years of CYBERTEC, our CEO gave some interesting insights into what he expects of the future - for the company as well as PostgreSQL as a whole.

CYBERTEC in another 25 years

Interviewer: Let's talk about the future. Where do you think you see CYBERTEC in another 25 years? 

Postgres database-level “synchronous replication” does not actually mean the replication is synchronous. It’s a bit of a lie really. The replication is actually – always – asynchronous. What it actually means is “when the client issues a COMMIT then pause until we know the transaction is replicated.” In fact the primary writer database doesn’t need to wait for the replicas to catch up UNTIL the client issues a COMMIT …and even then it’s only a single individual connection which waits. This has many interesting properties.

PostgreSQL logical replication adoption is becoming more popular as significant advances continue to expand its range of capabilities.  While quite a few blogs have described features, there seems to be a lack of simple and straightforward advice on restoring stalled replication. This blog demonstrates an extremely powerful approach to resolving replication problems using the Log […]

I volunteered as a room host and Slonik guide.
Best gig: posing our elephant. The photographer had runway-level ideas. Slonik delivered every single time.