PostgreSQL development is now done with periodic pauses to review and commit patches that have been submitted, called Commit Fests. The patches themselves are stored on a custom web app, and documentation about the process is on the PostgreSQL wiki. I’m returning to the role of CommitFest manager for this one, which means I get to harass people all month trying to get patch review finished. There are currently 26 patches that have no reviewer assigned to them. If you were ever interested in making a contribution to the PostgreSQL code base, getting involved in the review process is a great way to learn the attributes of patches that are committed, and to see how others fail to gain traction.
I submitted three patches myself this time, and one of them got comitted in the first day. Count backend self-sync calls hooks into the existing pg_stat_bgwriter statistics mechanism, tracking the hopefully rare situation where client backends are forced to not only write their own data blocks to disk, but to then execute an fsync call to make sure that write is durable afterwards too.
I don’t submit too many patches, but have a good track record for the ones I send being accepted. This patch demonstrates why I think that is. All of the following elements are present:
- Properly formed patch in expected format, refreshed against the latest PostgreSQL codebase just before submission to avoid “bit rot” since when I last worked on it.
- Description of the situation where users would find this patch useful, based on behavior seen on a user’s system. Too many people submit theoretical patches whose real-world value is hard to see; those are much harder to justify adding into the code base. You have to remember that every patch added increases the maintenance burden of the project, so new additions have to exceed that overhead to be worthwhile.
- Example output showing the patch operating as expected.
- Test program allowing a reviewer or committer to immediately see the patch give useful results when testing.
- Full documentation updates for the relevant changes, matching the style of the documentation around it.
- Warnings about parts of the code that are useful for testing the patch, but that are candidates to remove before commit. I also like to be clear about which parts of the patch I have not tested fully or are suspicious of. With this community, if you do something wrong but warned that you weren’t sure about that part up-front, that is more likely to lead to supportive feedback than if you hide the bad parts and leave them for reviewers to find.
- Keep the patch short. This one was under 200 lines of code. I had three related patches that I could have easily submitted as one big one instead; the result would have been over 600 lines. Breaking them into distinct pieces was more work for me, but it makes life much easier for reviewers and committers trying to consume and understand the code. The odds of your patch begin rejected are strongly correlated with how long it is; shorter patches are absorbed far more easily by the community development process.
If you do all those things, the odds of your patch making it successfully through the CommitFest process and becoming a change for the next version of PostgreSQL improve. And if you want more insight into the day to day details of how that works, the easiest way to get started is by selecting a patch by someone else you’re interested in to review. Seeing how others successfully add features is a great learning tool, particularly with a codebase as large as PostgreSQL where it’s difficult to just start from scratch and find something useful to adjust without getting lost along the way.