Reviewing a patch
Choose a patch you can understand, try it, and report what you found. A useful review may cover documentation, behavior, tests, or code. It does not have to be a complete architectural review.
1. Read before reviewing
Section titled “1. Read before reviewing”Choose an entry in the official tracker, then read the linked discussion and latest patch version. Look for open questions and existing reviewer feedback. Sign up as a reviewer when you plan to work on it so others can see your intention.
2. Test a concrete question
Section titled “2. Test a concrete question”Can you apply the patch? Does the feature behave as described? Do its documentation and tests cover the case you tried? Start with a bounded question that matches your experience. Follow the official reviewer guide for build and testing details rather than assuming one setup fits every patch.
3. Reply in the existing thread
Section titled “3. Reply in the existing thread”Reply to the patch email, keeping the thread intact. State the version tested, relevant setup, the steps you took, and observed results. Distinguish a reproduced problem from a hypothesis. Partial findings can still help.
4. Keep others informed
Section titled “4. Keep others informed”If you need more time, say so. Review feedback can lead to another revision; a committer makes the final decision. See Understanding CommitFest for the difference between review status and a released feature.
References
Section titled “References”- Reviewing a Patch — PostgreSQL wiki
- Reviewed October 28, 2026. This is an independent guide, not an official PostgreSQL website.