diff --git a/doc/src/sgml/problems.sgml b/doc/src/sgml/problems.sgml index 91626d90b2..54e4909fe6 100644 --- a/doc/src/sgml/problems.sgml +++ b/doc/src/sgml/problems.sgml @@ -1,5 +1,5 @@ @@ -39,7 +39,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe 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 the program does something different from what the + 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: @@ -123,31 +123,36 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe - 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 - query-language 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 start at 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. + 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. + - If your application uses some other client interface, such as PHP, then + 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 + start at 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 mid-size databases, etc. since this + 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. @@ -212,10 +217,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe postmaster --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. You can also look into the - README file - in the source directory or at the - name of your distribution file or package name. + more than old enough to warrant an upgrade. If you run a prepackaged version, such as RPMs, say so, including any subversion the package may have. If you are talking about a CVS snapshot, mention that, including its date and time. @@ -264,7 +266,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe just say PostgreSQL crashes. A crash of a single backend server process is quite different from crash of the parent postmaster process; please don't say the postmaster - crashed when you mean a single backend went down, nor vice versa. + 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. @@ -294,7 +296,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe pgsql-sql@postgresql.org or pgsql-general@postgresql.org. These mailing lists are for answering - user questions and their subscribers normally do not wish to receive + user questions, and their subscribers normally do not wish to receive bug reports. More importantly, they are unlikely to fix them. @@ -302,7 +304,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe Also, please do not send reports to the developers' mailing list pgsql-hackers@postgresql.org. This list is for discussing the - development of PostgreSQL and it would be nice + 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. @@ -327,7 +329,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 pe Due to the unfortunate amount of spam going around, all of the above email addresses are closed mailing lists. That is, you need to be subscribed to a list to be allowed to post on it. (You need not be - subscribed to use the bug report web-form, however.) + subscribed to use the bug-report web form, however.) If you would like to send mail but do not want to receive list traffic, you can subscribe and set your subscription option to nomail. For more information send mail to