How to contribute

PostgreSQL has been developed for almost three decades using a mailing-list-driven workflow that predates pull-request culture and shows no signs of changing. The GitHub mirror at github.com/postgres/postgres is read-only; pull requests opened against it are closed automatically. This page gives an opinionated tour of what actually works.

The canonical references are:

• The Developer FAQ on wiki.postgresql.org.
• The "Submitting a Patch" wiki page.
• The mailing list archives at https://www.postgresql.org/list/.
• The Commitfest app at https://commitfest.postgresql.org/.

Where the work happens

Channel	Purpose
pgsql-hackers@lists.postgresql.org	Design, code review, all patches. The single most important list.
pgsql-bugs@lists.postgresql.org	Bug reports (often filed via the form on postgresql.org).
pgsql-docs@lists.postgresql.org	Documentation patches.
pgsql-committers@lists.postgresql.org	One-way: commit notifications.
Commitfest app	Tracks patches through review cycles.

If a patch is not on pgsql-hackers, it does not exist. The workflow is: post a patch to the list, get review, post a revision, get more review, eventually a committer picks it up and pushes it.

Patch format

PostgreSQL prefers context diffs (diff -c or git format-patch-style patches) attached to email. A typical patch email contains:

1. A short summary of what the patch does and why.
2. Discussion of any controversial design choices.
3. Notes about test coverage, performance impact, and follow-ups.
4. The patch as an attachment (.patch or .diff).

git format-patch -1 produces an acceptable patch. For multi-step series, use git format-patch -N and post them all in one email thread.

Coding conventions

• Tabs for indentation, 4-column wide. Never spaces.
• BSD-style brace placement ({ on its own line for functions, on the same line for control blocks).
• Snake_case for functions and variables; CamelCase for type and node names; UPPER_SNAKE for macros.
• No C++. No C99 features that aren't broadly supported (designated initializers are fine, but check current policy).
• pgindent is the canonical formatter. Run it before posting a patch. Source: src/tools/pgindent/.

See Patterns and conventions for the deeper style guide.

Definition of done

A patch is ready for commit when:

1. It applies cleanly against master.
2. It includes regression tests covering the new behavior (and any regressions it might cause).
3. make check-world passes.
4. The documentation (doc/src/sgml/) is updated for any user-visible change.
5. pgindent has been run.
6. typedefs.list is updated if you added a new typedef.
7. The patch has been reviewed by at least one community member, and either the author is a committer or a committer has agreed to handle the commit.

The commitfest

PostgreSQL has formalized review windows called commitfests. Five per year, each ~one month long. During a commitfest, the project tries to get a verdict on every registered patch: committed, rejected, "returned with feedback," or moved to the next CF.

Authors register their patches at https://commitfest.postgresql.org/. Reviewers self-assign. The commitfest manager nudges stalled threads. This is the single biggest source of momentum for non-trivial features — outside of commitfests, patches can sit on the list indefinitely.

What this wiki covers

The how-to-contribute pages document the day-to-day mechanics of working in the codebase, not the social process of getting a patch accepted. Specifically:

• Development workflow — branching, building, common commands.
• Testing — regression, isolation, TAP. How to run, how to add new tests.
• Debugging — gdb, ereport, common failure modes.
• Patterns and conventions — error handling, memory contexts, palloc, lock acquisition, naming.
• Tooling — pgindent, perltidy, build flags, code generators.

For the social process — how to find a mentor, how to get on the commitfest, how reviews work — read the Developer FAQ and lurk on pgsql-hackers for a few weeks before posting.