When you find a bug in PostgreSQL we want to hear about it. Your bug reports play an important part in making PostgreSQL more reliable because even the utmost care cannot guarantee that every part of PostgreSQL will work on every platform under every circumstance.
The following suggestions are intended to assist you in forming bug reports that can be handled in an effective fashion. No one is required to follow them but doing so tends to be to everyone's advantage.
We cannot promise to fix every bug right away. If the bug is obvious, critical, or affects a lot of users,chances are good that someone will look into it. It could also happen that we tell you to update to a newer version to see if the bug happens there. Or we might decide that the bug cannot be fixed before some major rewrite we might be planning is done. Or perhaps it is simply too hard and there are more important things on the agenda. If you need help immediately, consider obtaining a commercial support contract.
当发现PostgreSQL的bug时，请及时告知我们。因为无论如何细心也无法保证PostgreSQL的每一部分都在所有平台的任何场景下运行良好，所以，你的bug报告对于PostgreSQL的稳定性来说，至关重要。
以下建议旨在帮助您创建我们能够有效处理的bug报告。当然，并不是强制要求，但如果遵守的话，会对bug有效、尽快处理有很大的帮助。
我们并不能保证所有的bug能够立马修复。如果bug很明显、很关键或者影响了很多用户，那么会有人去处理它。但也有可能，我们会告诉你更新版本看bug是否还会发生。或者，这个bug可能会在我们发布的下一个大版本才会修复。又或者，修复这个bug太困难，而我们有更重要的规划去完成而没有时间去处理。如果你需要立即获得帮助，那么可以考虑找商务支持。
5.1. Identifying Bugs
Before you report a bug, please read and re-read the documentation to verify that you can really do whatever it is you are trying. If it is not clear from the documentation whether you can do something or not, please report that too; it is a bug in the documentation. If it turns out that a program does something different from what the documentation says, that is a bug. That might include, but is not limited to, the following circumstances:
• A program terminates with a fatal signal or an operating system error message that would point to a problem in the program. (A counterexample might be a “disk full” message, since you have to fix that yourself.)
• A program produces the wrong output for any given input.
• A program refuses to accept valid input (as defined in the documentation).
• A program accepts invalid input without a notice or error message. But keep in mind that your idea of invalid input might be our idea of an extension or compatibility with traditional practice.
• PostgreSQL fails to compile, build, or install according to the instructions on supported platforms.
Here “program” refers to any executable, not only the backend process.
Being slow or resource-hogging is not necessarily a bug. Read the documentation or ask on one of the mailing lists for help in tuning your applications. Failing to comply to the SQL standard is not necessarily a bug either, unless compliance for the specific feature is explicitly claimed.
Before you continue, check on the TODO list and in the FAQ to see if your bug is already known.If you cannot decode the information on the TODO list, report your problem. The least we can do is make the TODO list clearer.
5.1. Identifying Bugs
在报告错误之前，请再次依据文档进行确认你确实能做文档中所阐明的步骤。如果文档中对于你能做事情没有一个清晰的界定，那么请提交bug报告，这应该是文档中的bug。如果一个程序的数据库行为与文档所描述不同，那么就是一个bug。这可能包括，但不限于以下情形：
-
程序以指示程序存在问题的致命错误或操作系统错误信息而终止。（当然，像磁盘爆满这种报错，还是要自行解决的。）
-
给定的输入，得到了错误的输出
-
程序拒绝接受在文档中规定的有效输入
-
程序接受了无效输入，且没有提示或者错误信息。但请注意，你认为的无效输入可能是我们对于传统内容的扩展及兼容性支持。
-
根据相关的说明，在支持的平台上，PostgreSQL编译、构建、安装失败。
这里的程序，指的是任何可执行文件，而不仅仅是后台进程。
数据库变慢或者资源消耗过大，并不一定是bug。可以通过阅读文档或者在邮件列表中提问，以对应用系统进行优化。当然，没有完全兼容SQL标准也不一定是一个bug，除非对于该特定SQL标准的兼容是做了明确保证的。
在进行下一步操作之前，请先阅读TODO列表及FAQ，以确认该bug是否为已知bug。如果在TODO列表中没有找到bug的记录，那么可以提交bug报告了。而我们，至少可以保证及时的更新TODO列表。
5.2. What to Report
The most important thing to remember about bug reporting is to state all the facts and only facts. Do not speculate what you think went wrong, what “it seemed to do”, or which part of the program has a fault. If you are not familiar with the implementation you would probably guess wrong and not help us a bit. And even if you are, educated explanations are a great supplement to but no substitute for facts. If we are going to fix the bug we still have to see it happen for ourselves first. Reporting the bare facts is relatively straightforward (you can probably copy and paste them from the screen) but all too often important details are left out because someone thought it does not matter or the report would be understood anyway.
The following items should be contained in every bug report:
• The exact sequence of steps from program start-up necessary to reproduce the problem. This should be self-contained; it is not enough to send in a bare SELECT statement without the preceding CREATE TABLE and INSERT statements, if the output should depend on the data in the tables. We do not have the time to reverse-engineer your database schema, and if we are supposed to make up our own data we would probably miss the problem.
The best format for a test case for SQL-related problems is a file that can be run through the psql frontend that shows the problem. (Be sure to not have anything in your ~/.psqlrc start-up file.) An easy way to create this file is to use pg_dump to dump out the table declarations and data needed to set the scene, then add the problem query. You are encouraged to minimize the size of your example, but this is not absolutely necessary. If the bug is reproducible, we will find it either way.
If your application uses some other client interface, such as PHP, then please try to isolate the offending queries. We will probably not set up a web server to reproduce your problem. In any case remember to provide the exact input files; do not guess that the problem happens for “large files” or “midsize databases”, etc. since this information is too inexact to be of use.
• The output you got. Please do not say that it “didn't work” or “crashed”. If there is an error message, show it, even if you do not understand it. If the program terminates with an operating system error, say which. If nothing at all happens, say so. Even if the result of your test case is a program crash or otherwise obvious it might not happen on our platform. The easiest thing is to copy the output from the terminal, if possible.
Note
If you are reporting an error message, please obtain the most verbose form of the message. In psql, say \set VERBOSITY verbose beforehand. If you are extracting the message from the server log, set the run-time parameter log_error_verbosity to verbose so that all details are logged.
Note
In case of fatal errors, the error message reported by the client might not contain all the information available. Please also look at the log output of the database server. If you do not keep your server's log output, this would be a good time to start doing so.
• The output you expected is very important to state. If you just write “This command gives me that output.” or “This is not what I expected.”, we might run it ourselves, scan the output, and think it looks OK and is exactly what we expected. We should not have to spend the time to decode the exact semantics behind your commands. Especially refrain from merely saying that “This is not what SQL says/Oracle does.” Digging out the correct behavior from SQL is not a fun undertaking, nor do we all know how all the other relational databases out there behave. (If your problem is a program crash, you can obviously omit this item.)
• Any command line options and other start-up options, including any relevant environment variables or configuration files that you changed from the default. Again, please provide exact information.If you are using a prepackaged distribution that starts the database server at boot time, you should try to find out how that is done.
• Anything you did at all differently from the installation instructions.
• The PostgreSQL version. You can run the command SELECT version(); to find out the version of the server you are connected to. Most executable programs also support a --version option;at least postgres --version and psql --version should work. If the function or the options do not exist then your version is more than old enough to warrant an upgrade. If you run a prepackaged version, such as RPMs, say so, including any subversion the package might have. If you are talking about a Git snapshot, mention that, including the commit hash.
If your version is older than 11.2 we will almost certainly tell you to upgrade. There are many bug fixes and improvements in each new release, so it is quite possible that a bug you have encountered in an older release of PostgreSQL has already been fixed. We can only provide limited support for sites using older releases of PostgreSQL; if you require more than we can provide, consider acquiring a commercial support contract.
• Platform information. This includes the kernel name and version, C library, processor, memory information, and so on. In most cases it is sufficient to report the vendor and version, but do not assume everyone knows what exactly “Debian” contains or that everyone runs on i386s. If you have installation problems then information about the toolchain on your machine (compiler, make, and so on) is also necessary.
Do not be afraid if your bug report becomes rather lengthy. That is a fact of life. It is better to report everything the first time than us having to squeeze the facts out of you. On the other hand, if your input files are huge, it is fair to ask first whether somebody is interested in looking into it. Here is an article that outlines some more tips on reporting bugs.
Do not spend all your time to figure out which changes in the input make the problem go away. This will probably not help solving it. If it turns out that the bug cannot be fixed right away, you will still have time to find and share your work-around. Also, once again, do not waste your time guessing why the bug exists. We will find that out soon enough.
When writing a bug report, please avoid confusing terminology. The software package in total is called “PostgreSQL”, sometimes “Postgres” for short. If you are specifically talking about the backend process, mention that, do not just say “PostgreSQL crashes”. A crash of a single backend process is quite different from crash of the parent “postgres” process; please don't say “the server crashed” when you mean a single backend process went down, nor vice versa. Also, client programs such as the interactive frontend “psql” are completely separate from the backend. Please try to be specific about whether the problem is on the client or server side.
5.2. What to Report
报告bug的首要注意点是：陈述所有的事实，且只陈述事实。不要臆测。因为如果你不了解实现原理，那么可能就会猜错，从而对我们分析问题一点帮助都没有；而即使你了解实现原理，好的解释也仅仅是对事实的补充，而不能代替事实。而对于我们来说，如果要去修复这个bug，那么我们首先要复现它才可以。简单的陈述事实可能很简单（可能只是复制粘贴），但总会有人因为自作主张而忽略最为重要的细节。
每个bug报告中应包含以下内容：
-
重现bug所需的确切操作步骤。这应该是自包含的，比如，如果输出依赖于表中的数据，那么也应该包含相应的建表语句及insert数据的语句，而不仅仅是一个select语句。我们没有时间逆推你的库里面的配置，而且如果让我们自己创建数据，那么我们可能遇不到你所遇到的bug；
对于SQL相关的问题，最好的提交方式是提交一个可以直接在psql执行的脚本，并可以直接显示出问题。（但要确保在~./psqlrc文件中没有自定义配置）一个比较简单的方法是使用pg_dump导出所需的表及数据，并在后面附加上出现问题的 sql语句。虽然我们鼓励你尽量缩小示例的大小，但这不是必须的，因为如果bug是可重现的，那么无论如何，我们都会重现它的。
如果数据库使用了其他的客户端，比如PHP，那么请将有问题的语句分离出来。因为我们为了重现你的bug，而重新搭建一套PHP环的可能性不大。无论如何，请谨记：提供准确的描述，不要使用猜测性语言，比如：认为问题会在“大文件” 或者“中型数据库”的情形下发生等等，因为这对于重现问题来说，太模糊了。
-
对于你得到的输出，不要说“它不工作了”或者“它坏了”这种语言。如果有报错信息，即使你看不懂，也要贴出来。如果程序因为操作系统错误而终止，那么请将操作系统错误贴出来。如果什么都没有发生，那就说什么都没有发生。因为即使在你的环境中是一个程序崩溃或者其他明显的问题，而在我们的环境中可能并不会发生。当然，最简单的事情，还是直接复制粘贴报错内容。
注：
如果提交错误信息，请包涵详细的内容。在psql下，使用\set VERBOSITY获得详细信息。如果是从服务器日志中获取信息，请设置log_error_verbosity为verbose以确保所有的详细信息均已计入日志。
注：
对于致命错误，客户端报出来的信息可能并不是全的，也需要去检查下服务端的日志是否有异常。如果服务端没有设置保留日志，那么是时候开始保留了。
-
你需要讲明你期望的结果。如果你只是说“这个命令怎么给我了这样的结果呢”或者“这不是我想要的”，那么当我们运行并查看结果的时候，我们可能认为就应该这样啊，挺好的呀。我们不会花时间去解密你代码背后的故事。特别是不要只是说“这不是SQL的行为，或者Oracle不是这样的”。从SQL中挖掘正确的行为并不是一个容易的事情，而且，并不是我们所有人都清晰其他关系型数据库的实现方式。（当然，如果你的问题只是一个程序崩溃，那么可以忽略此建议）
-
任何命令行选项或者其他启动选项，包括你修改过的相关的环境变量或者配置文件。同样，请提供精确的信息。如果你使用的是随操作系统启动的预编译发行版，那么你应该弄明白它是如何实现的。
-
做的任何与安装说明不同的操作。
-
PostgreSQL的版本。可以使用命令select version();来查看你所连接的服务端的版本。大部分可执行程序支持--version选项，至少，postgres --version和psql --version应该是可用的。如果这些功能或选项在你的数据库中都不能使用，那么就该考虑升级了。如果使用了预先打包的版本，请告知，并包含子版本号。如果是GIT快照，那么请提及，并指出commit hash。
如果你的版本低于11.2，那么基本上，我们会建议你进行升级。因为新版本修复了很多的bug并做了改进，或许你在旧版本遇到的bug在新版本中已经解决掉了。对于旧版本的使用，我们仅能提供有限的支持。如果超出了我们的支持范围，建议
你走商务途径。
-
操作系统信息。包含内核名称及版本，C库，CPU，内存信息等等。大部分情况下，只提供生产商及版本即可，但万不可直接假设每个人都知道“Debian”的意思或者别人都是在i386运行数据库。如果你的问题是安装方面的，那么你机器上相关的整个工具链的信息都是需要的（编译器，make版本等）。
如果你的bug报告很冗长，不要恐慌，这就是生活啊。第一次就把事情说清楚总比我们一点点去挖掘要好的多。当然，如果你提交的文件内容很多，那么最好还是问下别人，是否有人有兴趣去研究它。可以参考着篇对于bug报告更详细介绍的 文章。
不要浪费时间纠结于查明如何修改输入可以避免这个问题，这对解决问题一般并没有什么帮助。而如果最终确认此bug不能及时解决，那么你依然有时间去查找并分享你的折中方案。还有，再次重申，不要将精力放到猜测bug为什么存在上， 我们会很快给出答案的。
当提交bug报告的时候，请准确使用术语。这个软件，一般称为“PostgreSQL”，也简称“Postgres”。如果你在谈论的是后台进程，那么不要简单的只是说“PostgreSQL挂掉了”，因为一个后天进程的崩溃与父进程“Postgres”崩溃 并不是一回事；当你想表达一个后台进程挂掉时，不要只是说“服务挂掉了”，反之亦然。还有，像psql等这种客户端是与数据库服务端分离的，所以请尝试说明白，问题是出在客户端还是服务端。
5.3. Where to Report Bugs
In general, send bug reports to the bug report mailing list at <pgsql-bugs@lists.postgresql.org>. You are requested to use a descriptive subject for your email message, perhaps parts of the error message.
Another method is to fill in the bug report web-form available at the project's web site. Entering a bug report this way causes it to be mailed to the <pgsql-bugs@lists.postgresql.org> mailing list.
If your bug report has security implications and you'd prefer that it not become immediately visible in public archives, don't send it to pgsql-bugs. Security issues can be reported privately to <security@postgresql.org>.
Do not send bug reports to any of the user mailing lists, such as <pgsql-sql@lists.postgresql.org> or <pgsql-general@lists.postgresql.org>. These mailing lists are for answering user questions, and their subscribers normally do not wish to receive bug reports. More importantly, they are unlikely to fix them.
Also, please do not send reports to the developers' mailing list <pgsql-hackers@lists.postgresql.org>. This list is for discussing the development of PostgreSQL, and it would be nice if we could keep the bug reports separate. We might choose to take up a discussion about your bug report on pgsql-hackers, if the problem needs more review.
If you have a problem with the documentation, the best place to report it is the documentation mailing list <pgsql-docs@lists.postgresql.org>. Please be specific about what part of the documentation you are unhappy with.
If your bug is a portability problem on a non-supported platform, send mail to <pgsql-hackers@lists.postgresql.org>, so we (and you) can work on porting PostgreSQL to your platform.
Note
Due to the unfortunate amount of spam going around, all of the above lists will be moderated unless you are subscribed. That means there will be some delay before the email is delivered. If you wish to subscribe to the lists, please visit https://lists.postgresql.org/ for instructions.
5.3. Where to Report Bugs
一般，可以直接将错误报告发送到<pgsql-bugs@lists.postgresql.org>。当然，邮件的标题要对问题的描述有帮助，比如直接使用报错信息的一部分。
还一种方法是填写网站上的bug报告模板。填写此模板会将信息发送到<pgsql-bugs@lists.postgresql.org>。
如果你提交的bug报告中涉密或者不想让别人知道，那么可以将信息发送到私密邮箱<security@postgresql.org>。
不要将bug报告发送到用户邮箱列表，比如<pgsql-sql@lists.postgresql.org> 、 <pgsql-general@lists.postgresql.org>。这些邮箱是用以回复用户提问的，它们的订阅者一般不太想收到bug报告。而且，他们应该也不会对bug修复有帮助。
还有，不要将bug报告发送到开发者邮箱<pgsql-hackers@lists.postgresql.org>。这个邮件列表是用以讨论PostgreSQL开发的，最好将开发与bug报告区分开。如果你提交的问题需要更深入的探讨，那么我们会在pgsql-hackers进行探讨。
如果对该文档有疑问，那么可以发送邮件到<pgsql-docs@lists.postgresql.org>。当然，要说清楚文档的具体那部分让你不爽了。
如果你的问题是对于不支持平台的移植问题，那么可以发送邮件到<pgsql-hackers@lists.postgresql.org>，我们可以一起去解决这个问题。
注：
由于当前垃圾邮件泛滥，所以在发送之前，会有一个审核过程，所以在电子邮件发送之前会有一定时间的延迟。如果要订阅，那么可以到https://lists.postgresql.org/上去查看说明。
439
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
