注意: 在致命错误的情况中，客户端报告的错误消息可能不会包含所有可用的信息。请也看看数据库服务器的日志输出。如果你没有保留你的服务器的日志输出，这将是一个最好的时机开始记录它。
你所期望的输出也是需要说明的很重要的内容。如果你只写"这个命令给我那个输出。"或"这不是我所期待的。"，我们可能自己运行它、扫描输出并且认为它看起来 OK 并且正是我们期望的。我们不会花时间来理解你的命令背后的准确语义。特别是避免仅仅说"这不是 SQL 所说的/oracle 所作的。"从文章勾勒了一些报告缺陷的提示。
不要把你所有的时间花费在指出输入中的哪些改变让问题消失。这可能对解决问题没有什么帮助。如果发现缺陷不能被立马解决，你将还有时间去寻找和分享你的解决方法。同样，不要浪费你的时间去猜测为什么缺陷会存在。我们将尽快找出原因。
在编写一份缺陷报告使，请避免使用含糊的术语。这个软件包从整体上被称为"PostgreSQL"，有时会简称为"Postgres"。如果你要谈论特定的后端进程，不要只说"PostgreSQL 崩溃了"。一个单一后端进程的崩溃和其父"postgres"进程崩溃是完全不同的；当你想说一个单一后端进程垮掉时，请不要说"服务器崩溃了"，反之亦然。还有，如交互式前端"psql"等的客户端程序和后端是完全独立的。请尽量确定问题是发生在客户端还是服务器端。
另一种方法是填写项目网站上的缺陷报告网页表格。以这种方式输入的缺陷报告会被发送到<[email protected]>邮件列表。
如果你的缺陷报告牵涉到安全并且你不想让它立刻变得公众可见，不要把它发送到pgsql-bugs。安全问题可以被私下报告给<[email protected]>。
不要将缺陷报告发送到任何一个用户邮件列表，例如<[email protected]>或<[email protected]>。这些邮件列表是用来回答用户问题的，并且它们的订阅者通常不希望收到缺陷报告。更重要的是，他们不可能去修复缺陷。
另外，请不要把报告发送给开发者邮件列表<[email protected]>。这个列表是用来讨论PostgreSQL开发的地方，并且把缺陷报告隔离开对我们会比较好。如果问题需要更多的审查，我们可能选择在pgsql-hackers上对你的缺陷报告展开一次讨论。
如果你有一个关于文档的问题，报告它最好的地方是文档邮件列表<[email protected]>。请指出你对文档的哪个部分不爽。
如果你的缺陷是一个在非被支持平台上的移植性问题，请发送邮件到<[email protected]>，这样我们（和你）就可以做些工作把PostgreSQL移植到你的平台。
注意: 由于大量的垃圾邮件的出现，所有上述邮件地址都是封闭的邮件列表。也就是说，你需要订阅一个列表才能被允许在其中发帖（不过，使用缺陷报告网页表格不需要订阅）。如果你喜欢发送邮件但是不想收到列表，你可以订阅并且把订阅选项设置为nomail。更多信息请发送邮件给
<[email protected]>，在消息正文中包含一个单一单词help。