PostgreSQL is one of the most welcoming open-source projects. This module guides you through the contribution process, from finding issues to getting your first patch committed.
# Find TODO comments in sourcegrep -r "TODO" src/backend/ | head -50grep -r "FIXME" src/backend/grep -r "XXX" src/backend/ # Needs attention# Example findings:# src/backend/commands/tablecmds.c:/* TODO: check for pending triggers */# src/backend/optimizer/path/allpaths.c:/* XXX: consider partitionwise join */
Open Bugs
Copy
Check: https://www.postgresql.org/list/pgsql-bugs/Look for:• Bugs with minimal reproducers• Issues in areas you understand• Bugs that have been confirmed but not fixed• Old bugs that might have been fixed in recent commits
Commitfest Needs Review
Copy
Check: https://commitfest.postgresql.org/Filter by:• Status: "Needs Review"• Author: Anyone (avoid your own)• Target: Current or next releaseEven reviewing and testing counts as contribution!
Missing Tests
Copy
# Find untested code paths./configure --enable-coveragemake checkmake coverage-html# Look for red (uncovered) lines in:# htmlcov/src/backend/*/index.html# Write tests for uncovered edge cases
1. Go to https://lists.postgresql.org/2. Subscribe to pgsql-hackers (for patches)3. Subscribe to pgsql-general (for context)4. Read archives to understand culture and expectations5. Lurk for a few weeks before posting
# Start from latest mastergit checkout mastergit pull origin master# Create feature branchgit checkout -b my-feature# Make your changesvim src/backend/commands/myfile.c# Commit with good messagegit commit -m "Add feature X to command YThis patch adds support for X when using command Y.Previously, users had to manually do Z, which was error-prone.Discussion: https://postgr.es/m/MESSAGE-ID"# Generate patchgit format-patch master --stdout > my-feature.patch
# Full regression testmake check# Specific testsmake check TESTS="select insert update"# Isolation tests (for concurrency)make check -C src/test/isolation# Your new testsmake check TESTS="my-new-test"# Different configurations./configure --enable-cassertmake check# Different platforms (if possible)# Test on Linux, macOS, Windows
To: [email protected]Subject: [PATCH] Add feature X to command YHi hackers,Attached is a patch that adds support for X when using command Y.== Background ==Currently, when users want to do Z, they need to manually perform steps A, B, and C. This is error-prone because [reasons].== Solution ==This patch adds a new option '--foo' to the Y command that automatically handles Z.== Usage Example == $ pg_dump --foo mydb > backup.sql== Compatibility ==This patch is backward compatible. Existing scripts continue to work.== Testing ==- Added regression tests in src/test/regress/sql/pg_dump.sql- Tested on Linux x86_64 with PostgreSQL master- make check passes== Open Questions ==1. Should --foo be the default in v18?2. Is the error message clear enough?Please review!-- Your Name[Attach: v1-0001-Add-feature-X-to-command-Y.patch]
1. Go to https://commitfest.postgresql.org/2. Click "Add Entry"3. Fill in: - Name: "Add feature X to command Y" - Topics: Choose relevant area - Authors: Your name and email - Reviewers: Leave empty (others will pick up) - Thread URL: Link to your pgsql-hackers email4. Submit and wait for review
# Run pgindent on your filesrc/tools/pgindent/pgindent src/backend/commands/myfile.c# Common issues:# - Tabs vs spaces (use tabs)# - Line length (< 80 chars)# - Brace style (K&R for functions)# - Comment style (/* ... */ not //)
Reviewer says: “Needs regression tests”
Copy
-- Add to src/test/regress/sql/mytest.sql-- Test normal caseSELECT my_new_function(1, 2);-- Test edge casesSELECT my_new_function(NULL, 2);SELECT my_new_function(1, NULL);-- Test error casesSELECT my_new_function(-1, 2); -- should error
Reviewer says: “Please document the new option”
Copy
<!-- Add to doc/src/sgml/ref/pg_dump.sgml --><varlistentry> <term><option>--foo</option></term> <listitem> <para> Enable automatic Z handling. When this option is specified, the dump will include additional metadata for feature X. </para> </listitem></varlistentry>
Reviewer says: “Have you considered approach B instead?”
Copy
Response format:Hi [Reviewer],Thanks for the review!> Have you considered approach B instead?I did consider B, but chose A because:1. [Technical reason]2. [Performance reason]3. [Compatibility reason]That said, I'm open to changing if the consensus prefers B.What do others think?-- Your Name
# Make requested changesvim src/backend/commands/myfile.c# Commit as new versiongit add -Agit commit --amend # Or new commit if complex# Generate new patch versiongit format-patch master --stdout > v2-my-feature.patch# Reply to thread with new version
> I don't think we need this feature. Users can already do X.Thanks for the feedback. I see your point about X.However, I think this is still valuable because:1. The current workaround requires 3 steps2. It's error-prone (see bug #1234)3. Other databases have this built-inWould it help if I showed some user requests from the mailing list?If the consensus is against, I'm happy to withdraw the patch.I appreciate you taking the time to review!-- Your Name
Year 1:├── Review 10+ patches (easier than writing)├── Submit 2-3 doc fixes├── Fix 1-2 small bugs└── Attend PGConf (virtual or in-person)Year 2:├── Regular reviews (become known)├── Submit minor features├── Write blog posts about PostgreSQL internals└── Help newcomers on mailing listsYear 3+:├── Tackle larger features├── Get nominated for contributor awards├── Become go-to person for specific area└── Potentially become a committer