From c30446b9c901b357f9a7b859c51bee5740ac313f Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 17 Jun 2009 21:58:49 +0000 Subject: Proofreading for Bruce's recent round of documentation proofreading. Most of those changes were good, but some not so good ... --- doc/src/sgml/mvcc.sgml | 76 ++++++++++++++++++++++++++++++-------------------- 1 file changed, 45 insertions(+), 31 deletions(-) (limited to 'doc/src/sgml/mvcc.sgml') diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index 4637f0ae28e..4213216cc47 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -1,4 +1,4 @@ - + Concurrency Control @@ -246,7 +246,7 @@ committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. In effect, a SELECT query sees - a snapshot of the database at the instant the query begins to + a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed. Also note that two successive @@ -260,7 +260,7 @@ FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows - that were committed before the command start time. However, such a target + that were committed as of the command start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the would-be updater will wait for the first updating transaction to commit or @@ -367,16 +367,17 @@ COMMIT; transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions. (However, - SELECT does see the effects of previous updates + the query does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) This is different from Read Committed in that - SELECT in a serializable transaction - sees a snapshot as of the start of the transaction, not as of the start + a query in a serializable transaction + sees a snapshot as of the start of the transaction, + not as of the start of the current query within the transaction. Thus, successive SELECT commands within a single - transaction see the same data, i.e. they never see changes made by - transactions that committed after its own transaction started. (This - behavior can be ideal for reporting applications.) + transaction see the same data, i.e., they do not see changes made by + other transactions that committed after their own transaction started. + (This behavior can be ideal for reporting applications.) @@ -384,7 +385,7 @@ COMMIT; FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows - that were committed before the transaction start time. However, such a + that were committed as of the transaction start time. However, such a target row might have already been updated (or deleted or locked) by another concurrent transaction by the time it is found. In this case, the @@ -666,9 +667,10 @@ SELECT SUM(value) FROM mytab WHERE class = 2; - Conflicts all lock modes except ACCESS SHARE, - ROW SHARE, and SHARE (it - does not conflict with itself). + Conflicts with the ROW EXCLUSIVE, + SHARE UPDATE EXCLUSIVE, SHARE ROW + EXCLUSIVE, EXCLUSIVE, and + ACCESS EXCLUSIVE lock modes. This mode protects a table against concurrent data changes. @@ -685,8 +687,11 @@ SELECT SUM(value) FROM mytab WHERE class = 2; - Conflicts all lock modes except ACCESS SHARE - and ROW SHARE. + Conflicts with the ROW EXCLUSIVE, + SHARE UPDATE EXCLUSIVE, + SHARE, SHARE ROW + EXCLUSIVE, EXCLUSIVE, and + ACCESS EXCLUSIVE lock modes. @@ -702,7 +707,11 @@ SELECT SUM(value) FROM mytab WHERE class = 2; - Conflicts all lock modes except ACCESS SHARE. + Conflicts with the ROW SHARE, ROW + EXCLUSIVE, SHARE UPDATE + EXCLUSIVE, SHARE, SHARE + ROW EXCLUSIVE, EXCLUSIVE, and + ACCESS EXCLUSIVE lock modes. This mode allows only concurrent ACCESS SHARE locks, i.e., only reads from the table can proceed in parallel with a transaction holding this lock mode. @@ -711,7 +720,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2; This lock mode is not automatically acquired on user tables by any PostgreSQL command. However it is - acquired during certain internal system catalogs operations. + acquired on certain system catalogs in some operations. @@ -722,7 +731,12 @@ SELECT SUM(value) FROM mytab WHERE class = 2; - Conflicts with all lock modes. + Conflicts with locks of all modes (ACCESS + SHARE, ROW SHARE, ROW + EXCLUSIVE, SHARE UPDATE + EXCLUSIVE, SHARE, SHARE + ROW EXCLUSIVE, EXCLUSIVE, and + ACCESS EXCLUSIVE). This mode guarantees that the holder is the only transaction accessing the table in any way. @@ -749,7 +763,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2; Once acquired, a lock is normally held till end of transaction. But if a lock is acquired after establishing a savepoint, the lock is released - immediately if the savepoint is rolled back. This is consistent with + immediately if the savepoint is rolled back to. This is consistent with the principle that ROLLBACK cancels all effects of the commands since the savepoint. The same holds for locks acquired within a PL/pgSQL exception block: an error escape from the block @@ -882,8 +896,8 @@ SELECT SUM(value) FROM mytab WHERE class = 2; can be exclusive or shared locks. An exclusive row-level lock on a specific row is automatically acquired when the row is updated or deleted. The lock is held until the transaction commits or rolls - back, like table-level locks. Row-level locks do - not affect data querying; they only block writers to the same + back, just like table-level locks. Row-level locks do + not affect data querying; they block only writers to the same row. @@ -918,7 +932,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2; used to control read/write access to table pages in the shared buffer pool. These locks are released immediately after a row is fetched or updated. Application developers normally need not be concerned with - page-level locks, but they are mentioned for completeness. + page-level locks, but they are mentioned here for completeness. @@ -1100,7 +1114,7 @@ SELECT pg_advisory_lock(q.id) FROM after the current query began). The row might have been modified or deleted by an already-committed transaction that committed after the SELECT started. - Even if the row is still valid now, it could be changed or + Even if the row is still valid now, it could be changed or deleted before the current transaction does a commit or rollback. @@ -1121,7 +1135,7 @@ SELECT pg_advisory_lock(q.id) FROM concurrent updates one must use SELECT FOR UPDATE, SELECT FOR SHARE, or an appropriate LOCK TABLE statement. (SELECT FOR UPDATE - or SELECT FOR SHARE lock just the + and SELECT FOR SHARE lock just the returned rows against concurrent updates, while LOCK TABLE locks the whole table.) This should be taken into account when porting applications to @@ -1151,9 +1165,9 @@ SELECT pg_advisory_lock(q.id) FROM - Note also that if one is - relying on explicit locking to prevent concurrent changes, one should use - either Read Committed mode, or in Serializable mode be careful to obtain + Note also that if one is relying on explicit locking to prevent concurrent + changes, one should either use Read Committed mode, or in Serializable + mode be careful to obtain locks before performing queries. A lock obtained by a serializable transaction guarantees that no other transactions modifying the table are still running, but if the snapshot seen by the @@ -1162,7 +1176,7 @@ SELECT pg_advisory_lock(q.id) FROM frozen at the start of its first query or data-modification command (SELECT, INSERT, UPDATE, or DELETE), so - it is often desirable to obtain locks explicitly before the snapshot is + it is possible to obtain locks explicitly before the snapshot is frozen. @@ -1178,7 +1192,7 @@ SELECT pg_advisory_lock(q.id) FROM Though PostgreSQL provides nonblocking read/write access to table - data, nonblocking read/write access is currently not offered for every + data, nonblocking read/write access is not currently offered for every index access method implemented in PostgreSQL. The various index types are handled as follows: @@ -1221,8 +1235,8 @@ SELECT pg_advisory_lock(q.id) FROM Short-term share/exclusive page-level locks are used for read/write access. Locks are released immediately after each - index row is fetched or inserted. But note insertion of a GIN-indexed - value usually produces several index key insertions + index row is fetched or inserted. But note that insertion of a + GIN-indexed value usually produces several index key insertions per row, so GIN might do substantial work for a single value's insertion. -- cgit v1.2.3