Takeaways from the First 6 Months of Hacking on Postgres | PGConf EU 2022 | Melih Mutlu

Postgres is growing – in usage, in popularity and in the size of the community. And as usage grows, more and more people are wanting to contribute to PostgreSQL as well. However, getting started in Postgres development is more than simply coding a feature or fixing a bug. It’s understanding the codebase, the community, the processes.

Melih is a Postgres newbie and a developer in the early stages of his career who has only been working with Postgres for 6 months. In this talk, he will share his first experiences with Postgres. What were the difficulties for him? What made it easier to hack Postgres? Some tips for getting started and what we can do as a community to improve the process. Finally, we will end with how he ended up with my first contribution to logical replication. If you’re a new developer wanting to contribute to Postgres or want to hear how my journey is going as a newcomer, please join him.

Transcript

1. Takeaways from
   the First 6 Months of
   Hacking on Postgres
   Melih Mutlu
   @melihmtl
   PGConf.EU 2022, Berlin
   

   View Slide

2. About Me
   • Melih (@melihmtl)
   • Software Engineer
   • Joined Microsoft in 2019 as new grad
   • Worked on Hyperscale Citus (Cosmos DB for PosgtreSQL now)
   • In 2022, switched to Open-source Postgres team at Microsoft
   • Working full-time on contributing Postgres as part of my job.
   

   View Slide

3. In this talk
   You will witness a beginner’s journey of sending a patch for Postgres
   Goal:
   • Helping newcomers like me.
   • Feedback to community about
   the onboarding process.
   Mostly based on (but not all) my experiences
   

   View Slide

4. Spoilers!
   Where did I end up after this first 6 months:
   • Still working on Postgres.
   • Sent 5 patches so far.
   • 2 of them are committed
   • CI, logical replication, pg_buffercache
   

   View Slide

5. Outline
   • Why contribute to open source & Postgres
   • How to start with development
   • Where to start
   • Working on a patch
   • Coding
   • Sending to mailing list
   • Dealing with reviews
   • Reviewing a patch
   

   View Slide

6. Why contribute open-source & ?
   • Open-source software is cool!
   • Numerous exciting projects to work on.
   • It’s a plus and looks good on resume.
   • Postgres has lots of users and getting even more popular.
   

   View Slide

7. Concerns about starting with
   • What do I know about databases?
   • Are there enough opportunities?
   • Looks a bit scary
   

   View Slide

8. Okay,
   Let’s contribute to Postgres
   

   View Slide

9. But how to start?
   

   View Slide

10. How to start
    Some resources:
    • Wiki
    https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
    • Previous talks
    • Blog posts
    

    View Slide

11. How to start?
    Some concepts that were new to me:
    • Patch
    • Alright, git can create a patch.
    

    View Slide

12. How to start?
    Some concepts that were new to me:
    • Mailing list
    • Wait, are they sending changes via e-mail?
    

    View Slide

13. • Mailing lists are used for many
    open-source projects
    • Not used to mailing lists if new
    in open-source
    

    View Slide

14. How to start?
    If you’re scared away by how things work in Postgres
    Keep in mind that:
    • Git does the work for patches.
    • Don’t get too overwhelmed when writing an e-mail.
    • Yes, it goes to hundreds of inboxes. But, people don’t read every e-mail.
    

    View Slide

15. Where to start
    

    View Slide

16. Where should I start first?
    • Is there a todo list?
    • https://wiki.postgresql.org/wiki/Todo
    • Bug list?
    • pgsql-bugs? (another mailing list)
    • What’s there for beginners?
    • [E] -> easier to implement
    • Only 3 [E]’s
    

    View Slide

17. What could have helped?
    Resources that show the way to newcomers for their first patch would
    be helpful
    • More beginner-friendly labels on tasks.
    • Easier way to keep track of bugs.
    

    View Slide

18. How I picked my first tasks
    • Pulled the Postgres code and tried to build it with different options.
    • Read the docs and noted places that might be improved.
    • Discussed with Postgres committers in my team.
    

    View Slide

19. Keep in mind
    • Start with something small.
    • Discuss your idea with hackers first.
    • Go to hackers with some metrics to explain your reasoning.
    

    View Slide

20. Start coding…
    

    View Slide

21. Be aware!
    • C is not the easiest programming language.
    • Especially you haven’t used it again after CS 101 course in university.
    • Postgres has its own way to do some stuff.
    • You may not find your answer by googling.
    

    View Slide

22. Where to get help
    • Community
    • Mostly welcoming and helpful to newcomers
    • Archived knowledge on mailing list
    But:
    • Hard to get an answer if you’re not known
    

    View Slide

23. Where to get help
    • Documentation
    • Comprehensive
    But:
    • User focused
    

    View Slide

24. Where to get help
    • Comments
    • Helps a lot to understand the code
    But:
    • Not everywhere
    • May omit information sometimes
    

    View Slide

25. Send the patch to mailing list
    

    View Slide

26. But before anything
    Here are some mistakes I did with my patches:
    • Comments
    • Documentation changes
    • Tests
    • Add new one if needed
    • Run CI
    • pgindent
    • Commit message
    http://cfbot.cputube.org/
    https://cirrus-ci.com/github/postgres/postgres/
    

    View Slide

27. The patch is ready now
    • Congrats on your first patch!
    • I guess someone will review it.
    • Right?
    

    View Slide

28. Okay, now what?
    Your patch may wait there in silence…
    for a really long time.
    Don’t forget to create commitfest entry for your patch!
    

    View Slide

29. Suddenly, got a feedback
    • Addressed the issues mentioned
    • Then, I got more reviews
    • I didn’t understand what they wanted
    • I can always ask, they’re nice people.
    • Continued to update the patch as reviewers wanted more changes
    • Reviewers began to discuss more stuff
    • And, I got lost…
    

    View Slide

30. Tips for better review experience
    • Remember my mistakes with patches. Don’t do those!
    • Accept that you will have to make a lot of changes.
    • Be prepared to wait.
    • Be professional and polite in the mailing list.
    • One hacker saying that it’s a bad idea does not mean it’s bad.
    • Think about the scope of the patch beforehand.
    • If no feedback is there yet, update the patch by rebasing, fixing minor
    typos, adding a new comment. Then, gently ping the thread.
    

    View Slide

31. How to improve the patch experience
    • Simplify the process of creating and sending a patch.
    • Provide reviews with more beginner friendly explanations.
    • State explicitly if you’re waiting something from author.
    • Stay focused on the patch in the patch’s thread.
    • The faster patch process is, the more newcomers stay motivated.
    • Keep being professional and polite in the mailing list.
    

    View Slide

32. Patch reviews
    should be a good way to learn about Postgres!
    

    View Slide

33. What’s nice about patch reviews?
    • Increase your knowledge about a part of the codebase.
    • See how experienced hackers code.
    • Better code may reduce review cycles for the next patch.
    • More reviewers help to solve long waiting times issue for new
    patches.
    • Wouldn’t this be great for everyone?
    

    View Slide

34. My biggest struggle with patch reviews
    • I’m used to review code on platforms with nice looking UI
    Navigating to GitHub branches created by cfbot on helps.
    https://github.com/postgresql-cfbot/postgresql/tree/commitfest//
    

    View Slide

35. Wait, how would anyone know?
    

    View Slide

36. Is the work visible?
    • You have contributed to Postgres!
    • But how can anyone see my colors of productivity?
    

    View Slide

37. Is the work visible?
    • Attending conferences, meetups etc.
    • Publishing blog posts about your work.
    https://www.citusdata.com/blog/2022/09/30/how-to-add-more-environments-to-postgres-ci/
    

    View Slide

38. Last words…
    • Each patch has its own journey.
    • Please share your tricks that can be useful for others.
    

    View Slide

39. Thanks for listening!
    Twitter: @melihmtl
    

    View Slide