|
| 1 | +<!-- |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl Exp $ |
| 3 | +--> |
| 4 | + |
1 | 5 | <sect1 id="bug-reporting"> |
2 | 6 | <title>Bug Reporting Guidelines</title> |
3 | 7 |
|
|
119 | 123 | The exact sequence of steps <emphasis>from program start-up</emphasis> |
120 | 124 | necessary to reproduce the problem. This should be self-contained; |
121 | 125 | it is not enough to send in a bare select statement without the |
122 | | - preceeding create table and insert statements, if the output should |
| 126 | + preceding create table and insert statements, if the output should |
123 | 127 | depend on the data in the tables. We do not have the time |
124 | | - to decode your database schema, and if we are supposed to make up |
125 | | - our own data we would probably miss the problem. |
| 128 | + to reverse-engineer your database schema, and if we are supposed to make |
| 129 | + up our own data we would probably miss the problem. |
126 | 130 | The best format for a test case for |
127 | 131 | query-language related problems is a file that can be run through the |
128 | 132 | <application>psql</application> frontend |
129 | 133 | that shows the problem. (Be sure to not have anything in your |
130 | | - <filename>~/.psqlrc</filename> start-up file.) You are encouraged to |
| 134 | + <filename>~/.psqlrc</filename> start-up file.) An easy start at this |
| 135 | + file is to use <application>pg_dump</application> to dump out the table |
| 136 | + declarations and data needed to set the scene, then add the problem |
| 137 | + query. |
| 138 | + You are encouraged to |
131 | 139 | minimize the size of your example, but this is not absolutely necessary. |
132 | 140 | If the bug is reproduceable, we will find it either way. |
133 | 141 | </para> |
|
155 | 163 | <para> |
156 | 164 | In case of fatal errors, the error message provided by the client might |
157 | 165 | not contain all the information available. In that case, also look at the |
158 | | - output of the database server. If you do not keep your server output, |
159 | | - this would be a good time to start doing so. |
| 166 | + log output of the database server. If you do not keep your server |
| 167 | + output, this would be a good time to start doing so. |
160 | 168 | </para> |
161 | 169 | </note> |
162 | 170 | </listitem> |
|
224 | 232 | processor, memory information. In most cases it is sufficient to report |
225 | 233 | the vendor and version, but do not assume everyone knows what exactly |
226 | 234 | "Debian" contains or that everyone runs on Pentiums. If |
227 | | - you have installation problems information about compilers, make, etc. |
228 | | - is also necessary. |
| 235 | + you have installation problems then information about compilers, make, |
| 236 | + etc. is also necessary. |
229 | 237 | </para> |
230 | 238 | </listitem> |
231 | 239 | </itemizedlist> |
|
302 | 310 | <para> |
303 | 311 | Due to the unfortunate amount of spam going around, all of the above |
304 | 312 | email addresses are closed mailing lists. That is, you need to be |
305 | | - subscribed to them in order to be allowed to post. If you simply |
| 313 | + subscribed to a list to be allowed to post on it. If you simply |
306 | 314 | want to send mail but do not want to receive list traffic, you can |
307 | | - subscribe to the special pgsql-loophole mailing list, which |
308 | | - allows you to post to all <productname>PostgreSQL</productname> |
309 | | - mailing lists without receiving any messages. Send email to |
310 | | - <email>pgsql-loophole-request@postgresql.org</email> |
311 | | - to subscribe. |
| 315 | + subscribe and set your subscription option to <literal>nomail</>. |
| 316 | + For more information send mail to |
| 317 | + <email>majordomo@postgresql.org</email> |
| 318 | + with the single word <literal>help</> in the body of the message. |
312 | 319 | </para> |
313 | 320 | </note> |
314 | 321 | </sect2> |
|
0 commit comments