Contributing to Postgres via Patch Review
Contributing to Postgres via Patch Review
Follow the journey of developers who created Citus, an open-source extension to Postgres, in their commitfest.
Join the DZone community and get the full member experience.Join For Free
Compliant Database DevOps and the role of DevSecOps DevOps is becoming the new normal in application development, and DevSecOps is now entering the picture. By balancing the desire to release code faster with the need for the same code to be secure, it addresses increasing demands for data privacy. But what about the database? How can databases be included in both DevOps and DevSecOps? What additional measures should be considered to achieve truly compliant database DevOps? This whitepaper provides a valuable insight. Get the whitepaper
Citus is an open-source extension to Postgres that transforms Postgres into a distributed database, scaling horizontally. The fact that Citus is built on top of Postgres is a huge benefit to our users: it means that when you choose Citus, you get all the great features that are available in Postgres. And Postgres itself is an awesome database. Awesome. As a team, we value the foundation we're built on and regularly aim to contribute back to it. We have a number of developers that have contributed to Postgres over the years from features like
watch, event triggers, and the PostgreSQL extension framework.
Recently, a few more of our engineers expressed an interest in giving back to the PostgreSQL community. In fact, it's a common question: How can we better help the PostgreSQL project? And a common answer is reviewing patches. To help kick-start that process, we organized a session and carved out a few days just for patch review during the most recent commitfest.
How Postgres Gets Developed
To better understand what patch reviews mean to Postgres, it is best to take a step back and understand the broader development process. PostgreSQL is released on a yearly basis. While Postgres 11 is likely to ship in fall of this year, we largely know the superset of what will be released. As developers want to contribute they start with an idea of occasionally a full patch as a discussion point on the mailing list. As these patches become more baked, they get put into a review process.
To help better coordinate reviews and features, there is a period known as a commitfest. Patches that have been submitted get reviewed, edited, and then eventually committed. In fact, there is a full commitfest application that you can check out to see which patches are in flight.
Reviewing PostgreSQL Patches
For each patch review, you'll want to first pull the patch, apply it, test that it works, then review the code itself. For larger patches that may involve performance optimizations or such, of course, the work to test/review may be much heavier.
To us, it seemed like a good idea to walk through the process as a team with those who had more experience reviewing Postgres patches. So, we invited our coworkers from Canada, France, and the Netherlands to our Istanbul office to hold a Citus Commitfest, a time where everybody collaborates to PostgreSQL by reviewing patches. We started with Dimitri Fontaine, a Citan and major PostgreSQL contributor going over the process, explaining the commitfest logic, pgsql-etiquette, the importance of patch reviews and helping committers, etc. Then, we had everybody pick at least two patches that they wanted to review and paired over on the common patches. Moreover, Dimitri and Eren did a live review of the patch they chose on screen and everybody else has contributed to the review process. This included downloading and applying the patch on PostgreSQL master branch, compiling, running tests, checking that the patch does what is intended, reviewing the code line by line, and finally sending an e-mail to pgsql-hackers about the review we did.
Eren and Dimitri picked the patch about sending an optional message in cases of backend cancellation and termination, authored by Daniel Gustafsson. Normally, when you run
pg_terminate_backend, the canceled/terminated backend shows a message like
ERROR: canceling statement due to user request or
terminating connection due to administrator command. The patch allows us to supply a message that will be appended to the original message. In other words, when we run
SELECT pg_terminate_backend(pid, 'triggered failover from the console'), the message will look like
terminating connection due to administrator command: triggered failover from the console in the logs. This can be helpful for communication between the app developers and DBAs or in our case of running a database as a service.
Lessons Learned Reviewing Patches
The most unfortunate part of reviewing the patch for the commitfest is that we didn't get through more. This was due to a bit of bad planning on our part... as part of team building we took a boat ride and most team members ended up seasick-which definitely impacted our productivity and our planned reviews.
Lesson learned: Don't mix Postgres and boats.
Lesson learned #2: Reviewing PostgreSQL patches for the commitfest, while a small gesture, felt great. I speak not only for myself but also for our team of database developers here at Citus: we look forward to contributing to the Postgres community by doing even more patch reviews going forward.
Published at DZone with permission of Craig Kerstiens , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.