From PostgreSQL wiki

Many people feel that they're not qualified to do a full review of patches submitted to PostgreSQL. If you're not already a committer, that's technically true in at least that sense, and since the project is so large it's quite difficult to understand the whole code base. But review includes many different tasks, and even if you can't do all of them you can help the project by taking on the earlier phases.

If you can apply a patch and you can use the new feature, you're already qualified to start reviewing it.

The eventual committer will do their own review before the patch goes into the codebase. The task of a reviewer is to take off load from committers by catching simple problems. The reviewer's job is not to guarantee some level of quality, but just to report any problems they are able to find. That task is done if you think the patch is ready for in-depth review from a committer. See this patch review as one example of the output a thorough review might produce. Reviews for other patches might, of course, contain different sections or for that matter, look completely different.

If you're capable of any of the following tasks, your help is welcome. See also Josh Tolley's presentation for a tongue-in-cheek but not inaccurate description of who is welcome, and Review of Patch Reviewing for a more serious look at the material that's covered here.

The current commitfest is here and has plenty of room for you to help. You can sign up to become a Round Robin Reviewer here. Once you have, write a mail to the list introducing yourself.

Reviews should be done with the configure options --enable-cassert and --enable-debug turned on; see Working with CVS for a full example. These will help find issues with the code that might otherwise be missed. But note a copy of PostgreSQL built using these parameters will be substantially slower than one built without them. If you're working on something performance-related, such as testing whether a patch slows anything down, be sure to build without these flags before testing execution speed. Some, but not all, of the penalty of --enable-cassert can be turned off at server start time by putting debug_assertions = false in your postgresql.conf. See Developer Options for more details about that setting; it defaults to true in builds done with --enable-cassert. Also note that while --enable-debug shouldn't have any performance penalty when building with gcc, it definitely does with most other compilers.