|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.577 2008/01/31 21:31:33 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.578 2008/02/02 23:30:23 tgl Exp $ --> |
2 | 2 | <!-- |
3 | 3 |
|
4 | 4 | Typical markup: |
@@ -697,13 +697,14 @@ current_date < 2017-11-17 |
697 | 697 |
|
698 | 698 | <para> |
699 | 699 | This feature dramatically increases performance for short data-modifying |
700 | | - transactions. The disadvantage is that because disk writes are |
701 | | -delayed,if the operating system crashes before data is written to |
702 | | - the disk, committed data will be lost. This feature is useful for |
| 700 | + transactions.The disadvantage is that because disk writes are delayed, |
| 701 | + if the database or operating system crashes before data is written to |
| 702 | + the disk, committed data will be lost.This feature is useful for |
703 | 703 | applications that can accept some data loss. Unlike turning off |
704 | | - <varname>fsync</varname>, asynchronous commit does not put database |
705 | | - consistency at risk; the worst case is that after a database or system |
706 | | - crash the last few reportedly-committed transactions might be missing. |
| 704 | + <varname>fsync</varname>, using asynchronous commit does not put |
| 705 | + database consistency at risk; the worst case is that after a crash the |
| 706 | + last few reportedly-committed transactions might not be committed after |
| 707 | + all. |
707 | 708 | This feature is enabled by turning off <varname>synchronous_commit</> |
708 | 709 | (which can be done per-session or per-transaction, if some transactions |
709 | 710 | are critical and others are not). |
|