|
1 | 1 | <!-- |
2 | | -$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.15 2000/07/16 14:47:57 petere Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.16 2000/07/17 22:32:44 tgl Exp $ |
3 | 3 | --> |
4 | 4 |
|
5 | 5 | <Chapter Id="runtime"> |
@@ -374,8 +374,8 @@ Is the postmaster running at 'localhost' and accepting connections on Unix socke |
374 | 374 | <para> |
375 | 375 | One way to set these options is to create a file |
376 | 376 | <filename>postgresql.conf</filename> in the data directory (e.g., |
377 | | - <filename>/usr/local/pgsql/data</filename>). An example ofhow |
378 | | - this file could look like is this: |
| 377 | + <filename>/usr/local/pgsql/data</filename>). An example ofwhat |
| 378 | + this file could look like is: |
379 | 379 | <programlisting> |
380 | 380 | # This is a comment |
381 | 381 | log_connections = yes |
@@ -829,15 +829,22 @@ env PGOPTIONS='--geqo=off' psql |
829 | 829 | <term>DEADLOCK_TIMEOUT (<type>integer</type>)</term> |
830 | 830 | <listitem> |
831 | 831 | <para> |
832 | | - <productname>Postgres</productname> assumes that if |
833 | | - transactions are stuck for this many milliseconds then a |
834 | | - deadlock has occurred. Although it is technically possible to |
835 | | - detect deadlocks <quote>properly</quote>, the present |
836 | | - optimistic approach is much more efficient in practice. If you get |
837 | | - too many deadlock detected messages when you provably did not |
838 | | - have one, you might want to try raising this value. The |
839 | | - default is 1000 (i.e., one second). This option can only be |
840 | | - set at server start. |
| 832 | + This is the amount of time, in milliseconds, to wait on a lock |
| 833 | +before checking to see if there is a deadlock condition or not. |
| 834 | +The check for deadlock is relatively slow, so we don't want to |
| 835 | +run it every time we wait for a lock. We (optimistically?) |
| 836 | +assume that deadlocks are not common in production applications, |
| 837 | +and just wait on the lock for awhile before starting to ask |
| 838 | +questions about whether it can ever get unlocked. |
| 839 | +Increasing this value reduces the amount of time wasted in |
| 840 | +needless deadlock checks, but slows down reporting of real deadlock |
| 841 | +errors. The default is 1000 (i.e., one second), which is probably |
| 842 | +about the smallest value you would want in practice. On a heavily |
| 843 | +loaded server you might want to raise it. Ideally the setting |
| 844 | +should exceed your typical transaction time, so as to improve the |
| 845 | +odds that the lock will be released before the waiter decides to |
| 846 | +check for deadlock. |
| 847 | +This option can only be set at server start. |
841 | 848 | </para> |
842 | 849 | </listitem> |
843 | 850 | </varlistentry> |
@@ -889,7 +896,8 @@ env PGOPTIONS='--geqo=off' psql |
889 | 896 | <para> |
890 | 897 | Determines how many concurrent connections the database server |
891 | 898 | will allow. The default is 32. There is also a compiled-in |
892 | | - hard upper limit on this option, which is currently 1024. This |
| 899 | + hard upper limit on this value, which is typically 1024 |
| 900 | +(both numbers can be altered when compiling the server). This |
893 | 901 | parameter can only be set at server start. |
894 | 902 | </para> |
895 | 903 | </listitem> |
|