|
| 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