diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index c8e263526e..77004beea4 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1,4 +1,4 @@ - + Backup and Restore @@ -1034,7 +1034,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' (The path name is relative to the working directory of the server, i.e., the cluster's data directory.) Any %r is replaced by the name of the file containing the - last valid restartpoint. That is the earliest file that must be kept + last valid restart point. That is the earliest file that must be kept to allow a restore to be restartable, so this information can be used to truncate the archive to just the minimum required to support restart of the current restore. %r would only be used in a @@ -1479,7 +1479,7 @@ if (!triggered) The size of the WAL archive can be minimized by using the %r option of the restore_command. This option specifies the - last archive filename that needs to be kept to allow the recovery to + last archive file name that needs to be kept to allow the recovery to restart correctly. This can be used to truncate the archive once files are no longer required, if the archive is writable from the standby server. diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 6c7684a471..a2f95b209c 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1,4 +1,4 @@ - + Server Configuration @@ -608,7 +608,7 @@ SET ENABLE_SEQSCAN TO OFF; - Sets the realm to match Kerberos, GSSAPI and SSPI usernames against. + Sets the realm to match Kerberos, GSSAPI and SSPI user names against. See , or for details. This parameter can only be set at server start. @@ -3166,12 +3166,11 @@ local0.* /var/log/postgresql Including csvlog in the log_destination list provides a convenient way to import log files into a database table. This option emits log lines in comma-separated-value format, - with these columns: timestamp with milliseconds, username, database - name, session id, host:port number, process id, per-process line - number, command tag, session start time, virtual transaction id, + with these columns: timestamp with milliseconds, user name, database + name, session ID, host:port number, process ID, per-process line + number, command tag, session start time, virtual transaction ID, regular transaction id, error severity, SQL state code, error message. Here is a sample table definition for storing CSV-format log output: - CREATE TABLE postgres_log @@ -3193,15 +3192,16 @@ CREATE TABLE postgres_log PRIMARY KEY (session_id, process_line_num) ); + To import a log file into this table, use the COPY FROM command: - COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; + There are a few things you need to do to simplify importing CSV log @@ -3221,7 +3221,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; Set log_rotation_size to 0 to disable - size-based log rotation, as it makes the log filename difficult + size-based log rotation, as it makes the log file name difficult to predict. diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 5525ebb5bd..2bb325a99b 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1,4 +1,4 @@ - + Data Definition @@ -2793,7 +2793,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01'; range tests for range partitioning, as illustrated in the preceding examples. A good rule of thumb is that partitioning constraints should contain only comparisons of the partitioning column(s) to constants - using btree-indexable operators. + using B-tree-indexable operators. diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index c08fe3cecf..9662090d56 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -1,4 +1,4 @@ - + Functions and Operators @@ -1313,7 +1313,7 @@ ASCII code of the first character of the argument. For UTF8 returns the Unicode code - point of the character. For other multi-byte encodings. the + point of the character. For other multibyte encodings. the argument must be a strictly ASCII character. ascii('x') @@ -1338,7 +1338,7 @@ text Character with the given code. For UTF8 the - argument is treated as a Unicode code point. For other multi-byte + argument is treated as a Unicode code point. For other multibyte encodings the argument must designate a strictly ASCII character. @@ -1359,7 +1359,7 @@ src_encoding. The string must be valid in this encoding. Conversions can be defined by CREATE CONVERSION. - Also there are some pre-defined conversions. See for available conversions. convert('text_in_utf8', 'UTF8', 'LATIN1') @@ -6823,7 +6823,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple Notice that except for the two-argument form of enum_range, these functions disregard the specific value passed to them; they care - only about its declared datatype. Either NULL or a specific value of + only about its declared data type. Either null or a specific value of the type can be passed, with the same result. It is more common to apply these functions to a table column or function argument than to a hardwired type name as suggested by the examples. @@ -8381,7 +8381,7 @@ cursor_to_xml(cursor refcursor, count int, nulls boolean, tableforest boolean, t ... ]]> - If no table name is avaible, that is, when mapping a query or a + If no table name is available, that is, when mapping a query or a cursor, the string table is used in the first format, row in the second format. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 38ac8653cf..33bced7344 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ - + High Availability, Load Balancing, and Replication @@ -66,7 +66,7 @@ Performance must be considered in any choice. There is usually a - tradeoff between functionality and + trade-off between functionality and performance. For example, a full synchronous solution over a slow network might cut performance by more than half, while an asynchronous one might have a minimal performance impact. @@ -202,13 +202,13 @@ protocol to make nodes agree on a serializable transactional order. - Asynchronous Multi-Master Replication + Asynchronous Multimaster Replication For servers that are not regularly connected, like laptops or remote servers, keeping data consistent among servers is a - challenge. Using asynchronous multi-master replication, each + challenge. Using asynchronous multimaster replication, each server works independently, and periodically communicates with the other servers to identify conflicting transactions. The conflicts can be resolved by users or conflict resolution rules. @@ -217,18 +217,18 @@ protocol to make nodes agree on a serializable transactional order. - Synchronous Multi-Master Replication + Synchronous Multimaster Replication - In synchronous multi-master replication, each server can accept + In synchronous multimaster replication, each server can accept write requests, and modified data is transmitted from the original server to every other server before each transaction commits. Heavy write activity can cause excessive locking, leading to poor performance. In fact, write performance is often worse than that of a single server. Read requests can be sent to any server. Some implementations use shared disk - to reduce the communication overhead. Synchronous multi-master + to reduce the communication overhead. Synchronous multimaster replication is best for mostly read workloads, though its big advantage is that any server can accept write requests — there is no need to partition workloads between master and @@ -279,8 +279,8 @@ protocol to make nodes agree on a serializable transactional order. Warm Standby Using PITR Master-Slave Replication Statement-Based Replication Middleware - Asynchronous Multi-Master Replication - Synchronous Multi-Master Replication + Asynchronous Multimaster Replication + Synchronous Multimaster Replication @@ -401,7 +401,7 @@ protocol to make nodes agree on a serializable transactional order. - Multi-Server Parallel Query Execution + Multiple-Server Parallel Query Execution diff --git a/doc/src/sgml/install-win32.sgml b/doc/src/sgml/install-win32.sgml index 9d96abeaa8..a87f52d5b7 100644 --- a/doc/src/sgml/install-win32.sgml +++ b/doc/src/sgml/install-win32.sgml @@ -1,4 +1,4 @@ - + Installation on <productname>Windows</productname> @@ -82,7 +82,7 @@ ActiveState Perl ActiveState Perl is required to run the build generation scripts. MinGW - or Cygwin perl will not work. It must also be present in the PATH. + or Cygwin Perl will not work. It must also be present in the PATH. Binaries can be downloaded from . @@ -209,7 +209,7 @@ To change the default build configuration to debug, put the following - in the buildenv.bat file: + in the buildenv.bat file: set CONFIG=Debug @@ -261,8 +261,8 @@ To run the regression tests, make sure you have completed the build of all required parts first. Also, make sure that the DLLs required to load all - parts of the system (such as the perl and python DLLs for the procedural - languages) are present in the system PATH. If they are not, set it through + parts of the system (such as the Perl and Python DLLs for the procedural + languages) are present in the system path. If they are not, set it through the buildenv.bat file. To run the tests, run one of the following commands from the src\tools\msvc directory: @@ -282,7 +282,7 @@ To change the schedule used (default is the parallel), append it to the - commandline like: + command line like: vcregress check serial @@ -321,7 +321,7 @@ - DocBook DSSL 1.79 + DocBook DSSSL 1.79 Download from diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 9c761aba56..193348cd52 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1,4 +1,4 @@ - + <![%standalone-include[<productname>PostgreSQL</>]]> @@ -1308,7 +1308,7 @@ su - postgres <term><envar>TCLSH</envar></term> <listitem> <para> - Full path to the Tcl interpreter. This wil be used to + Full path to the Tcl interpreter. This will be used to determine the dependencies for building PL/Tcl. </para> </listitem> diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 7aa142800e..3acbe2c3d3 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.246 2007/09/26 08:45:50 momjian Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.247 2007/11/28 15:42:31 petere Exp $ --> <chapter id="libpq"> <title><application>libpq</application> - C Library @@ -4976,7 +4976,7 @@ defaultNoticeProcessor(void *arg, const char *message) used. (Therefore, put more-specific entries first when you are using wildcards.) If an entry needs to contain : or \, escape this character with \. - A host name of localhost matches both TCP (hostname + A host name of localhost matches both TCP (host name localhost) and Unix domain socket (pghost empty or the default socket directory) connections coming from the local machine. diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 33b86818ca..26d9d5e045 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -1,4 +1,4 @@ - + Routine Database Maintenance Tasks @@ -115,7 +115,7 @@ UPDATE or DELETE of a row does not immediately remove the old version of the row. This approach is necessary to gain the benefits of multiversion - concurrency control (see ): the row version + concurrency control (see ): the row versions must not be deleted while it is still potentially visible to other transactions. But eventually, an outdated or deleted row version is no longer of interest to any transaction. The space it occupies must be @@ -486,7 +486,7 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb". Beginning in PostgreSQL 8.3, autovacuum has a - multi-process architecture: there is a daemon process, called the + multiprocess architecture: There is a daemon process, called the autovacuum launcher, which is in charge of starting an autovacuum worker process on each database every seconds. On each run, the worker diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 2fea0a75b2..4d25b41bfa 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -1,4 +1,4 @@ - + Monitoring Database Activity @@ -236,7 +236,7 @@ postgres: user database host One row only, showing cluster-wide statistics from the background writer: number of scheduled checkpoints, requested checkpoints, buffers written by checkpoints and cleaning scans, - and the number of times the bgwriter stopped a cleaning scan + and the number of times the background writer stopped a cleaning scan because it had written too many buffers. Also includes statistics about the shared buffer pool, including buffers written by backends (that is, not by the background writer) and total buffers @@ -777,7 +777,7 @@ postgres: user database host pg_stat_get_bgwriter_timed_checkpoints() bigint - The number of times the bgwriter has started timed checkpoints + The number of times the background writer has started timed checkpoints (because the checkpoint_timeout time has expired) @@ -786,7 +786,7 @@ postgres: user database host pg_stat_get_bgwriter_requested_checkpoints() bigint - The number of times the bgwriter has started checkpoints based + The number of times the background writer has started checkpoints based on requests from backends because the checkpoint_segments has been exceeded or because the CHECKPOINT command has been issued @@ -797,7 +797,7 @@ postgres: user database host pg_stat_get_bgwriter_buf_written_checkpoints() bigint - The number of buffers written by the bgwriter during checkpoints + The number of buffers written by the background writer during checkpoints @@ -805,7 +805,7 @@ postgres: user database host pg_stat_get_bgwriter_buf_written_clean() bigint - The number of buffers written by the bgwriter for routine cleaning of + The number of buffers written by the background writer for routine cleaning of dirty pages @@ -814,7 +814,7 @@ postgres: user database host pg_stat_get_bgwriter_maxwritten_clean() bigint - The number of times the bgwriter has stopped its cleaning scan because + The number of times the background writer has stopped its cleaning scan because it has written more buffers than specified in the bgwriter_lru_maxpages parameter @@ -1180,7 +1180,7 @@ provider postgresql { You should take care that the data types specified for the probe arguments - match the datatypes of the variables used in the PG_TRACE + match the data types of the variables used in the PG_TRACE macro. This is not checked at compile time. You can check that your newly added trace point is available by recompiling, then running the new binary, and as root, executing a DTrace command such as: diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 1d3b8484f5..07c6db6992 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -1,4 +1,4 @@ - + Performance Tips @@ -738,10 +738,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; and are similarly named because they do almost the same thing: one controls - when the planner will flatten out subselects, and the + when the planner will flatten out subqueries, and the other controls when it will flatten out explicit joins. Typically you would either set join_collapse_limit equal to - from_collapse_limit (so that explicit joins and subselects + from_collapse_limit (so that explicit joins and subqueries act similarly) or set join_collapse_limit to 1 (if you want to control join order with explicit joins). But you might set them differently if you are trying to fine-tune the trade-off between planning diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index 4cbb9c4df5..185dc3eaf8 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -1,4 +1,4 @@ - + <application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language @@ -3348,7 +3348,7 @@ SELECT * INTO myrec FROM dictionary WHERE word LIKE search_term; where search_term is a PL/pgSQL variable. The cached plan for this query will never use an index on word, since the planner cannot assume that the - LIKE pattern will be left-anchored at runtime. To use + LIKE pattern will be left-anchored at run time. To use an index the query must be planned with a specific constant LIKE pattern provided. This is another situation where EXECUTE can be used to force a new plan to be diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index c6f29c496c..d6bf184d64 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -1,5 +1,5 @@ @@ -214,7 +214,7 @@ where action is one of: of course the integrity of the constraint cannot be guaranteed if the triggers are not executed. The trigger firing mechanism is also affected by the configuration - variable . Simply ENABLEd + variable . Simply enabled triggers will fire when the replication role is origin (the default) or local. Triggers configured ENABLE REPLICA will only fire if the session is in replica mode and triggers diff --git a/doc/src/sgml/ref/create_operator.sgml b/doc/src/sgml/ref/create_operator.sgml index 0b8e9fbe4d..4eea6d213c 100644 --- a/doc/src/sgml/ref/create_operator.sgml +++ b/doc/src/sgml/ref/create_operator.sgml @@ -1,5 +1,5 @@ @@ -222,9 +222,9 @@ COMMUTATOR = OPERATOR(myschema.===) , The obsolete options SORT1, SORT2, LTCMP, and GTCMP were formerly used to - specify the names of sort operators associated with a mergejoinable + specify the names of sort operators associated with a merge-joinable operator. This is no longer necessary, since information about - associated operators is found by looking at btree operator families + associated operators is found by looking at B-tree operator families instead. If one of these options is given, it is ignored except for implicitly setting MERGES true. diff --git a/doc/src/sgml/ref/delete.sgml b/doc/src/sgml/ref/delete.sgml index b5c7d97f52..6e3d9ff2c1 100644 --- a/doc/src/sgml/ref/delete.sgml +++ b/doc/src/sgml/ref/delete.sgml @@ -1,5 +1,5 @@ @@ -150,7 +150,7 @@ DELETE FROM [ ONLY ] table [ [ AS ] from this cursor. The cursor must be a simple (non-join, non-aggregate) query on the DELETE's target table. Note that WHERE CURRENT OF cannot be - specified together with a boolean condition. + specified together with a Boolean condition. diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml index 1a216f7c90..89fb0274ca 100644 --- a/doc/src/sgml/ref/explain.sgml +++ b/doc/src/sgml/ref/explain.sgml @@ -1,5 +1,5 @@ @@ -160,7 +160,7 @@ ROLLBACK; - In order to measure the runtime cost of each node in the execution + In order to measure the run-time cost of each node in the execution plan, the current implementation of EXPLAIN ANALYZE can add considerable profiling overhead to query execution. As a result, running EXPLAIN ANALYZE diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index 2165a63d4a..2624630699 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -1,5 +1,5 @@ @@ -698,7 +698,7 @@ SELECT name FROM distributors ORDER BY code; assumed by default. Alternatively, a specific ordering operator name can be specified in the USING clause. An ordering operator must be a less-than or greater-than - member of some btree operator family. + member of some B-tree operator family. ASC is usually equivalent to USING < and DESC is usually equivalent to USING >. (But the creator of a user-defined data type can define exactly what the diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml index 2c6a480c4a..ce05150073 100644 --- a/doc/src/sgml/ref/update.sgml +++ b/doc/src/sgml/ref/update.sgml @@ -1,5 +1,5 @@ @@ -169,7 +169,7 @@ UPDATE [ ONLY ] table [ [ AS ] UPDATE's target table. Note that WHERE CURRENT OF cannot be - specified together with a boolean condition. + specified together with a Boolean condition. diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index c08650dc28..6500314c05 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,4 +1,4 @@ - + Operating System Environment @@ -180,9 +180,9 @@ postgres$ initdb -D /usr/local/pgsql/data NFS implementations have non-standard semantics, this can cause reliability problems (see ). - Specifically, delayed (asynchonous) writes to the NFS + Specifically, delayed (asynchronous) writes to the NFS server can cause reliability problems; if possible, mount - NFS file systems synchonously (without caching) to avoid + NFS file systems synchronously (without caching) to avoid this. (Storage Area Networks (SAN) use a low-level communication protocol rather than NFS.) diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml index 533d64d070..e154f6a19b 100644 --- a/doc/src/sgml/textsearch.sgml +++ b/doc/src/sgml/textsearch.sgml @@ -1,4 +1,4 @@ - + Full Text Search @@ -32,7 +32,7 @@ Textual search operators have existed in databases for years. PostgreSQL has ~, ~*, LIKE, and - ILIKE operators for textual datatypes, but they lack + ILIKE operators for textual data types, but they lack many essential properties required by modern information systems: @@ -132,7 +132,7 @@ - Map synonyms to a single word using ispell. + Map synonyms to a single word using Ispell. @@ -145,7 +145,7 @@ Map different variations of a word to a canonical form using - an ispell dictionary. + an Ispell dictionary. @@ -725,7 +725,7 @@ UPDATE tt SET ti = to_tsquery creates a tsquery value from querytext, which must consist of single tokens - separated by the boolean operators & (AND), + separated by the Boolean operators & (AND), | (OR) and ! (NOT). These operators can be grouped using parentheses. In other words, the input to to_tsquery must already follow the general rules for @@ -783,7 +783,7 @@ SELECT to_tsquery('''supernovae stars'' & !crab'); plainto_tsquery transforms unformatted text querytext to tsquery. The text is parsed and normalized much as for to_tsvector, - then the & (AND) boolean operator is inserted + then the & (AND) Boolean operator is inserted between surviving words. @@ -798,7 +798,7 @@ SELECT to_tsquery('''supernovae stars'' & !crab'); Note that plainto_tsquery cannot - recognize either boolean operators or weight labels in its input: + recognize either Boolean operators or weight labels in its input: SELECT plainto_tsquery('english', 'The Fat & Rats:C'); @@ -1085,7 +1085,7 @@ ORDER BY rank DESC LIMIT 10; - HighlightAll: boolean flag; if + HighlightAll: Boolean flag; if true the whole document will be highlighted. @@ -1131,7 +1131,7 @@ query.', tsvector summary, so it can be slow and should be used with care. A typical mistake is to call ts_headline for every matching document when only ten documents are - to be shown. SQL subselects can help; here is an + to be shown. SQL subqueries can help; here is an example: @@ -1945,7 +1945,7 @@ SELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.h - Linguistic - ispell dictionaries try to reduce input words to a + Linguistic - Ispell dictionaries try to reduce input words to a normalized form; stemmer dictionaries remove word endings @@ -2395,7 +2395,7 @@ crab nebulae : crab Below we create a dictionary and bind some token types to - an astronomical thesaurus and english stemmer: + an astronomical thesaurus and English stemmer: CREATE TEXT SEARCH DICTIONARY thesaurus_astro ( @@ -2610,7 +2610,7 @@ CREATE TEXT SEARCH DICTIONARY english_stem ( Several predefined text search configurations are available, and you can create custom configurations easily. To facilitate management of text search objects, a set of SQL commands - is available, and there are several psql commands that display information + is available, and there are several psql commands that display information about text search objects (). @@ -2644,7 +2644,7 @@ CREATE TEXT SEARCH DICTIONARY pg_dict ( ); - Next we register the ispell dictionary + Next we register the Ispell dictionary english_ispell, which has its own configuration files: @@ -2834,7 +2834,7 @@ SELECT * FROM ts_debug('english','a fat cat sat on a mat - it ate a fat rats'); For a more extensive demonstration, we first create a public.english configuration and - ispell dictionary for the English language: + Ispell dictionary for the English language: diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index d1fa700ace..a1a3277434 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -1,4 +1,4 @@ - + Reliability and the Write-Ahead Log @@ -162,7 +162,7 @@ Asynchronous commit is an option that allows transactions to complete more quickly, at the cost that the most recent transactions may be lost if the database should crash. In many applications this is an - acceptable tradeoff. + acceptable trade-off. @@ -210,7 +210,7 @@ The user can select the commit mode of each transaction, so that it is possible to have both synchronous and asynchronous commit - transactions running concurrently. This allows flexible tradeoffs + transactions running concurrently. This allows flexible trade-offs between performance and certainty of transaction durability. The commit mode is controlled by the user-settable parameter , which can be changed in any of @@ -223,7 +223,7 @@ Certain utility commands, for instance DROP TABLE, are forced to commit synchronously regardless of the setting of synchronous_commit. This is to ensure consistency - between the server's filesystem and the logical state of the database. + between the server's file system and the logical state of the database. The commands supporting two-phase commit, such as PREPARE TRANSACTION, are also always synchronous. @@ -234,11 +234,11 @@ WAL records, then changes made during that transaction will be lost. The duration of the - risk window is limited because a background process (the wal + risk window is limited because a background process (the WAL writer) flushes unwritten WAL records to disk every milliseconds. The actual maximum duration of the risk window is three times - wal_writer_delay because the wal writer is + wal_writer_delay because the WAL writer is designed to favor writing whole pages at a time during busy periods. diff --git a/doc/src/sgml/xoper.sgml b/doc/src/sgml/xoper.sgml index 0a13ce7c43..628a5a91fa 100644 --- a/doc/src/sgml/xoper.sgml +++ b/doc/src/sgml/xoper.sgml @@ -1,4 +1,4 @@ - + User-Defined Operators @@ -340,7 +340,7 @@ table1.column1 OP table2.column2 some form of equality. In most cases it is only practical to support hashing for operators that take the same data type on both sides. However, sometimes it is possible to design compatible hash functions - for two or more datatypes; that is, functions that will generate the + for two or more data types; that is, functions that will generate the same hash codes for equal values, even though the values have different representations. For example, it's fairly simple to arrange this property when hashing integers of different widths. @@ -378,8 +378,8 @@ table1.column1 OP table2.column2 if they are different) that appears in the same operator family. If this is not the case, planner errors might occur when the operator is used. Also, it is a good idea (but not strictly required) for - a hash operator family that supports multiple datatypes to provide - equality operators for every combination of the datatypes; this + a hash operator family that supports multiple data types to provide + equality operators for every combination of the data types; this allows better optimization. @@ -450,8 +450,8 @@ table1.column1 OP table2.column2 if they are different) that appears in the same operator family. If this is not the case, planner errors might occur when the operator is used. Also, it is a good idea (but not strictly required) for - a btree operator family that supports multiple datatypes to provide - equality operators for every combination of the datatypes; this + a btree operator family that supports multiple data types to provide + equality operators for every combination of the data types; this allows better optimization.