POSETTE CFP is closed. Thanks to all submitters. Remember to save the date for POSETTE: An Event for Postgres 2024 📌
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 that had more experience reviewing Postgres patches. So we invited our coworkers from Canada, France and 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_cancel_backend or pg_terminate_backend, the cancelled/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 in 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 number 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.
