缺陷报告指南

当你在PostgreSQL中找到一个缺陷时,我们希望听到关于它的事情。你的缺陷报告在使得PostgreSQL更可靠的工作上扮演了重要的角色,因为再谨慎也不能保证PostgreSQL的每一部分都能在每一个平台上、每一种环境中工作。

下列建议目的是协助你把缺陷形成便于高效处理的形式。没有人被要求遵循它们,但是这样做对每个人都好。

我们无法保证马上修复每一个缺陷。如果缺陷是明显的、严重的或者影响很多用户,那么这是个好机会让某人去检查它。也可能我们会告诉你升级到一个新的版本来查看缺陷是否在该版本里也存在。或者我们可能决定在我们计划中的某些重大重写完成之前缺陷无法被修复。或者也许就是修复该缺陷太困难并且在日程表上还有更多重要的事情要做。如果你需要立即得到帮助,考虑联系一个商业支持。

标识缺陷

在你报告一个缺陷之前,请阅读再阅读文档来验证你真地可以做你正在尝试的任何东西。如果从文档中无法清楚地知道你是否能做某事,也请把它报告给我们;这是一个文档中的缺陷。如果发现一个程序做的事情和文档说的不一样,那就是一个缺陷。那可能包括(但不限于)下列情况:

这里的"程序"指任何可执行文件,不仅仅是后台进程。

很慢或者很占资源不一定是一个缺陷。阅读文档或者在邮件列表中寻求帮助来调优你的应用。无法符合SQL标准也不一定是一个缺陷,除非文档中已经明确地声明指定特性是兼容的。

在你继续之前,检查 TODO 列表和 FAQ 来看你的缺陷是否为已知。如果你不能理解 TODO 列表中的信息,那就报告你的问题。至少我们可以让 TODO 列表更清晰。

报告什么

关于缺陷报告要记住的最重要的事情是说明事实并且只说明事实。不要推断你觉得什么出错了、"它看起来在做"什么或者程序的哪一部分出错了。如果你不熟悉实现,你可能猜错并且不会帮到我们。而且即使你熟悉实现,受过训练的解释是巨大的补充但是也无法替代事实。如果我们想要修复缺陷,我们还是需要首先重现它。报告裸的事实相对直接(你可以直接从屏幕上拷贝和粘贴它们)但是可能有太多重要的细节被略去,因为某些人可能认为它不重要(所以没有包含在报告中)或者报告可能以其他方式被理解。

下列项应该被包含在每一个缺陷报告中:

不要担心你的缺陷报告变得太长。这就是生活。最好是第一次就报告所有的东西,而不是让我们去从你那里询问。在另一方面,如果你的输入文件太大,最好先问问是否有人有兴趣去看它。这里有一篇文章勾勒了一些报告缺陷的提示。

不要把你所有的时间花费在指出输入中的哪些改变让问题消失。这可能对解决问题没有什么帮助。如果发现缺陷不能被立马解决,你将还有时间去寻找和分享你的解决方法。同样,不要浪费你的时间去猜测为什么缺陷会存在。我们将尽快找出原因。

在编写一份缺陷报告使,请避免使用含糊的术语。这个软件包从整体上被称为"PostgreSQL",有时会简称为"Postgres"。如果你要谈论特定的后端进程,不要只说"PostgreSQL 崩溃了"。一个单一后端进程的崩溃和其父"postgres"进程崩溃是完全不同的;当你想说一个单一后端进程垮掉时,请不要说"服务器崩溃了",反之亦然。还有,如交互式前端"psql"等的客户端程序和后端是完全独立的。请尽量确定问题是发生在客户端还是服务器端。

向哪里报告缺陷

通常,请把缺陷报告发送到缺陷报告邮件列表。你会被要求给你的电子邮件消息加上一个描述性的主题,可以用错误消息的一部分。

另一种方法是填写项目网站上的缺陷报告网页表格。以这种方式输入的缺陷报告会被发送到邮件列表。

如果你的缺陷报告牵涉到安全并且你不想让它立刻变得公众可见,不要把它发送到pgsql-bugs。安全问题可以被私下报告给

不要将缺陷报告发送到任何一个用户邮件列表,例如。这些邮件列表是用来回答用户问题的,并且它们的订阅者通常不希望收到缺陷报告。更重要的是,他们不可能去修复缺陷。

另外,请要把报告发送给开发者邮件列表。这个列表是用来讨论PostgreSQL开发的地方,并且把缺陷报告隔离开对我们会比较好。如果问题需要更多的审查,我们可能选择在pgsql-hackers上对你的缺陷报告展开一次讨论。

如果你有一个关于文档的问题,报告它最好的地方是文档邮件列表。请指出你对文档的哪个部分不爽。

如果你的缺陷是一个在非被支持平台上的移植性问题,请发送邮件到,这样我们(和你)就可以做些工作把PostgreSQL移植到你的平台。

注意: 由于大量的垃圾邮件的出现,所有上述邮件地址都是封闭的邮件列表。也就是说,你需要订阅一个列表才能被允许在其中发帖(不过,使用缺陷报告网页表格不需要订阅)。如果你喜欢发送邮件但是不想收到列表,你可以订阅并且把订阅选项设置为nomail。更多信息请发送邮件给,在消息正文中包含一个单一单词help