Getting help, and helping out
pgAdmin is built by volunteers from around the world. There is no paid support, but there is an active mailing list, a public issue tracker and a development team that reads both.
Getting help
If you have a problem, please check the documentation first, and then search the mailing list archives; between them they cover most of what people run into. If neither answers the question, post to the support mailing list, where other users and the development team will see it.
In a hurry? The pgadmin-support mailing list is the fastest route to a human. Bugs belong on the issue tracker, and anything security related goes to the private address in security issues.
Release lifecycle
pgAdmin follows a rolling release policy: only the latest release is supported at any time. There are no back-branches and no long-term stable versions, so fixes and new features land in the next release rather than being backported.
The version number uses a major.minor format. A new release normally increments the minor number, though a change large enough to alter how the application feels to use may increment the major number instead. We aim to release roughly every six weeks, with the timing shifting around major holidays such as Christmas, New Year and Diwali, and we make out-of-cycle releases when a security fix calls for one.
Mailing list
The pgadmin-support@lists.postgresql.org list is intended for
end user support. If you believe you have found a bug you are welcome to
confirm it on the list first, but the issue tracker is where it needs to
end up.
- Subscribe and unsubscribe through the PGLister management interface.
- To leave quickly, email pgadmin-support-unsubscribe@lists.postgresql.org.
- Everything sent to the list is archived publicly and permanently in the PostgreSQL archives.
Issue tracker
Bugs and other issues are usually fixed within a very short time of being reported. Some are outside our control, and some would take more effort to resolve than the problem warrants, in which case they may stay open.
Before logging anything new, please check the existing issue list on the GitHub project; if you find one that matches, add whatever extra detail you can rather than opening a duplicate. When you do open an issue, try to include as much of the following as possible:
- The version of pgAdmin you are running, and where you obtained it.
- Whether you are running in server or desktop mode.
- The steps needed to reproduce the problem, with a simple schema and sample data if that is what it takes. This may be sent privately on request from a developer if you would rather not post code or data to a public list.
- The operating system and version.
- Any log output. The FAQ explains how to turn logging up.
Security issues
To report a security issue in pgAdmin, pgAgent or this website, email security (at) pgadmin (dot) org. That address is for reporting problems you believe you have found in the design or the code, not for asking security questions, which belong on the mailing list.
Advisories for past issues, with the affected versions and the releases that fixed them, are published on the security advisories page.
Helping us help you
General questions and discussion belong on the mailing list, and will be deleted if they are logged on the bug tracker instead.
Please do not email a developer directly: they might miss it, or might not be the right person at all, whereas the list makes sure your question is seen and answered in a timely fashion. Dave Page's blog includes a frank posting describing why this is a bad idea, whilst Eric Raymond's How to ask questions the smart way describes the best way to get the help you need.