In this post we'll introduce two memory leaks into Postgres and debug them with heaptrack. Like almost every memory leak tool available to us (including memleak which I wrote about last time), heaptrack requires you to be on Linux. But a Linux VM on a Mac is fine too (that is where I'm running this code from). Although we use Postgres as the codebase with which to explore tools like memleak (last...

In this post we'll set up a 3-node EDB Postgres Distributed (PGD) cluster running community Postgres 16. Then we'll upgrade the entire cluster in place from Postgres 16 to Postgres 17. We'll demonstrate that even while bringing individual nodes down for the major version upgrade, the cluster overall will remain available for reads and writes. There may be nuances to your particular environment...

The latest generation of programming languages (Rust, Go, Zig) come bundled not just with a standard library but with a suite of first-party tools for working with the code itself (e.g. cargo fmt, gofmt, zig fmt, etc.). But I suspect that some future generation of (statically typed) programming languages will also come with a first-party embedded scripting language to make it easier to write tests...

In this post we'll explore the basics of logical replication between two Postgres databases as both a user and a developer. Postgres first implemented physical replication where it shipped bytes on disk from one database A to another database B. Database B would write those bytes right back to disk. But this physical replication limits you to replicating between Postgres instances running the same Postgres version and on the same CPU architecture (and likely other operating system settings like page size).

Postgres manages memory through nested arenas called MemoryContexts. MemoryContexts are convenient because, for the most part, you don't need to worry about explicitly freeing memory because memory allocated within the context will be freed when the context is freed. So the next two things you worry about, things that took me a while to understand, are 1) in which MemoryContext should some...

Learn how EDB Postgres Distributed improves logical replication for seamless upgrades, high availability, and optimized DML performance in PostgreSQL clusters.

You’re looking for production-grade Postgres. You need to keep multiple copies of your data around for high-availability. And this data must stay consistent across the copies. You need to handle rolling upgrades of the cluster. You need to handle taking a node out of the cluster for maintenance. You need to handle DDL changes across nodes in the cluster. And we might be getting ahead of ourselves, but you may also need low-latency read replicas or even need to geo-distribute your data while adhering to data governance policies.

Despite powerful capabilities with many tasks, Large Language Models (LLMs) are not know-it-alls. If you've used ChatGPT or other models, you'll have experienced how they can’t reasonably answer questions about proprietary information. What’s worse, it isn’t just that they don't know about proprietary information, they are unaware of their own limitations and, even if they were aware, they don’t have access to proprietary information. That's where options like Retrieval Augmented Generation (RAG) come in and give LLMs the ability to incorporate new and proprietary information into their answers.

I spent the last week looking for a memory leak in Postgres’s WAL Sender process. I spent a few days getting more acquainted with Valgrind and gcc/clang sanitizers, but ultimately got nowhere useful with them. Finally, I stumbled on the memleak program from the bcc tools collection which led me right to the source. Since I had a bit of trouble figuring this all out for the first time, I wanted to share the process I went through. Working with some contrived memory leaks. Although this happened in Postgres, and this post introduces a leak into Postgres to set us up for an investigation, the techniques are broadly useful.