PostgreSQL

So, you might’ve caught my previous two blog posts where I explained on implementing an ABI compliance reporting system for PostgreSQL as a BuildFarm module. The initial approach involved cloning the PostgreSQL source code and looping through commits to pinpoint the exact commit responsible for any ABI breakage. But, after discussing with the community on the hackers list(here), a few key issues came to light: The original approach didn’t quite align with how the other BuildFarm modules functioned. Looping through commits introduced potential complications, especially when dealing with commits where source compilation might fail. Handling these edge cases would’ve added unnecessary complexity. Identifying the commit causing ABI breakage is usually pretty straightforward. Since the module typically runs on one or more BuildFarm animals, the number of commits between runs is small enough to easily spot the culprit. These points led to a shift in how the module actually works. Let’s call it ABI Compliance Reporting V2! ...

In my last post, “June, BuildFarm and ABIs” I mentioned my next step would be setting up the buildfarm server. However, plans have shifted slightly. This past week, I focused on minor bug fixes and, more importantly, figuring out how to send ABI compliance reports to the buildfarm server. So, let’s dive into the details of what I’ve been up to! Client changes Using abbreviated commit hashes for everything. Reducing code duplication. Fixing the run_branches.pl script. Sending results to the buildfarm server. The fourth task, sending results to the buildfarm, proved to be the most challenging. Initially, I thought it would be as simple as using the run_web_txn function from the web module. I tried get help using AI for this but it ended up generating some random AI slop which just don’t work as big tech tech don’t have much Perl codebases in their datasets lol. ...

If you might have read my previous blog posts, you would know that I am working on an automated ABI compliance reporting system for PostgreSQL as part of my GSoC 2025 project. In this blog post, I will discuss the current progress and implementation details of this system, as well as its integration with the PostgreSQL build farm. Current Progress According to my estimated timeline, I should have completed the basic implementation of the ABI compliance checker module and started receiving reports on the server by now. With a slight delay, the client implementation is almost complete (working on some changes) and the server implementation is in progress (trying to get better with CGI scripts). ...

If you have not read the part 1 of this blog, consider reading that to get some context where I will be starting this one from :D How PostgreSQL build farm will be used for this tool? The Implementation for this project will be divided in 3 major parts 1) Deciding the ABI Compliance checking tool As per this thread, for ABI compliance checking, abi-compliance-checker is a great choice which can also give its reports in HTML format, which makes it a very great fit for the project. But the abi-compliance-checker appears to be deprecated and unsupported upstream. So, I had to do some research into alternatives to that which can support multiple compilers and is actively maintained. ...

Who am I? I am Mankirat Singh, a 3rd Year Computer Engineering undergrad from India, passionate about building any piece of tech. This year, I will work with PostgreSQL to develop an ABI Compliance reporting system for the official PostgreSQL Repository under the Google Summer of Code 2025 Program. What is ABI and ABI Compliance Checking? ABI? ABI stands for Application Binary Interface. It is a set of rules and conventions that define how compiled code interacts with other compiled code at the binary level; This includes details about data types, function calling conventions, and binary formats. ...