PostgreSQL is the “Worlds Most Advanced Open Source Relational Database” (the website header says so, and I happen to agree).
One of the reasons PostgreSQL popularity continues to increase is because of how new features, bug fixes, and general discussions about improving Postgres are open for anyone to see. Some changes are proposed and merged quickly (relatively speaking). Other ideas might take a few years to discuss and implement in a way that garners wide support.
Although I’ve been using Postgres full-time again for the last 5 years, it’s only in the last 12 months or so that I’ve understood how open the development process is, and how easy it is for you and me to follow along. If you’ve lived most of your career working with proprietary database systems (even those based on Postgres), it might be hard to believe.
Five times a year, the Postgres project runs a Commitfest to track the patches submitted for inclusion in upcoming releases. These patches can be documentation changes, improvements for minor releases, or new features for upcoming major releases.
Jacob Champion, a colleague when I worked at Timescale, wrote a few articles about managing a Commitfest which are worth the read. As Timescale prepared to publish the articles, the internal review helped me better understand how unique the Postgres process is, especially among most major database platforms.
As a result of understanding this process better, I now make it a regular part of my week to review the open Commitfest. I scan the patches that are being worked on and dig a little deeper into the discussion of patches that catch my eye.
Don’t get me wrong. My (current) skillset isn’t to review Postgres C code with much ability to help that process. Yet, the discussion around patches and the opinions that folks share all contribute to improving Postgres release after release. For a Postgres enthusiast, this is a fascinating process to watch.
Which leads me to this new series, PostgreSQL Patch of Interest (to me).
I often find myself scanning the Commitfest application, clicking through to the associated pgsql-hackers email discussion, and thinking, “This is intriguing! I wonder what other non-hackers think about this?” There are too many patches in flight at any one time to mention them all, but I’m guessing at least one or two a month would trigger some interesting discussion.
My Ground Rules and Disclaimers
- I’m not a hard-core C developer and I still have a lot to learn about Postgres internals. I may never be up to the challenge of working on a patch myself. But maybe one day I’ll feel that I know enough to help review some. 🤞
- Most of the time this series will not be a deep dive into the actual patch itself. In fact, the discussion for a small patch can often span months of time, so I can’t even promise to dig into many details. 👷
- Any thoughts are only musings about the fix or feature and what it means to the wider Postgres discussion. You might not care if LZ4 compression is added to `pg_dump`, but I might happen to think it’s a pretty cool improvement. Let’s still be friends. 🤔
- I have no issues borrowing from other discussions about a patch if it seems relevant. I’ll attempt to faithfully give credit, but the goal is learning (both for myself and others). 🧑🎓
- If I miss a few weeks, life probably just got busy. I doubt I’ll ever run out of patches I find interesting, but there are only so many hours in a day. ⏱️
Following along at home
I’ll link to any patch I discuss, specifically in the Commitfest website. However, if you want to browse on your own or dig in for more detail, here are a few helpful things to know about the items you’ll encounter on the website.
Home
On the homepage you’ll see a listing of each commitfest back to December of 2014. If you want to see what patches were accepted into the review process of a prior release and what the outcome was, have a glance through anything labeled “Closed”. I’ll be looking at the Open and Future commitfest entries most of the time.
Commitfest Details
Once you’ve clicked into a Commitfest page, the table lists all patches currently attached to the open review session. There are headers (eg. “Bug Fixes”, “Clients”, “Documentation”, etc) interspersed throughout the table to group things together. The current status of a patch is listed, as well as the targeted PostgreSQL version.
Patch Detail
Next, you can click on the “title” of the patch to get to more detail, including how many commitfests this patch has been a part of. From here, the most interesting piece for me is the pgsql-hackers email thread that accompanies each patch. Clicking on the first link in the Emails section will direct you to the entire thread of discussion about the patch. I’m just warning you, some of these pages could be very long.
Which directs you to this:
What you see is the entire email thread for the referenced patch listed in chronological order. The first email you see in the thread is the original patch submission. Most often the original email has the initial patch file(s) attached. Sometimes, however, a feature currently included in a commitfest may have started with discussion of a feature that eventually turned into a working patch.
One final note if you haven’t watched the PostgreSQL mailing lists much. In general the email lists are anti-top posting. This means that all responses should quote the relevant parts of the email they are responding to and essentially make those responses in-line. You should not (or very rarely) see a response at the top of an email with no relevant quoted text. It’s easy to lose context with top-posting and you’ll find that the Postgres email list users are pretty pedantic about the best way to provide feedback through email.
Tracking the Changes
That’s the basic rundown of how I’ll be finding patches to discuss and how you can do the same. As I get to know more folks in the PostgreSQL community, including those that are contributing to the project on a regular basis, watching the development process unfold has been a very good learning opportunity. At the very least it helps me realize and remember that this project has been built by many dedicated people, over a very long time. Quite an achievement, and one that all users all benefit from! 🙏
Thanks, that’s a very informative post (sort of “what you always wanted to ask, but were not sure how :))”