Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3f86238

Browse files
author
Thomas G. Lockhart
committed
Make minor changes in wording.
Adjust tags to get a clean build.
1 parent0ac9555 commit3f86238

File tree

2 files changed

+101
-88
lines changed

2 files changed

+101
-88
lines changed

‎doc/src/sgml/ref/lock.sgml

Lines changed: 100 additions & 87 deletions
Original file line numberDiff line numberDiff line change
@@ -53,13 +53,13 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
5353
<para>
5454
This lock mode is acquired automatically over tables being queried.
5555
<productname>Postgres</productname> releases automatically acquired
56-
ACCESS SHARE locks after statement is done.
56+
ACCESS SHARE locks afterthestatement is done.
5757
</para>
5858
</note>
5959

60-
<para>
61-
This is theless restrictive lock mode which conflicts with
62-
ACCESS EXCLUSIVE mode only. It'sintended to protect table being
60+
<para>
61+
This is theleast restrictive lock mode which conflicts only with
62+
ACCESS EXCLUSIVE mode. It isintended to protect a table being
6363
queried from concurrent <command>ALTER TABLE</command>,
6464
<command>DROP TABLE</command> and <command>VACUUM</command>
6565
statements over the same table.
@@ -74,12 +74,12 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
7474
<listitem>
7575
<note>
7676
<para>
77-
Automatically acquired by <command>SELECT FOR UPDATE</command> statement.
78-
</para>
77+
Automatically acquired byany<command>SELECT FOR UPDATE</command> statement.
78+
</para>
7979
</note>
8080

81-
<para>
82-
Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
81+
<para>
82+
Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
8383
</para>
8484
</listitem>
8585
</varlistentry>
@@ -91,15 +91,15 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
9191
<listitem>
9292
<note>
9393
<para>
94-
Automatically acquired by <command>UPDATE</command>,
95-
<command>DELETE</command>, <command>INSERT</command>statements.
96-
</para>
97-
</note>
94+
Automatically acquired byany<command>UPDATE</command>,
95+
<command>DELETE</command>, <command>INSERT</command>statement.
96+
</para>
97+
</note>
9898

99-
<para>
99+
<para>
100100
Conflicts with SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
101101
ACCESS EXCLUSIVE modes. Generally means that a transaction
102-
updated/inserted some tuples in a table.
102+
updated orinserted some tuples in a table.
103103
</para>
104104
</listitem>
105105
</varlistentry>
@@ -111,14 +111,14 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
111111
<listitem>
112112
<note>
113113
<para>
114-
Automatically acquired by <command>CREATE INDEX</command> statement.
114+
Automatically acquired byany<command>CREATE INDEX</command> statement.
115115
</para>
116116
</note>
117117

118-
<para>
119-
Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
120-
ACCESS EXCLUSIVE modes. This mode protects a table against
121-
concurrent updates.
118+
<para>
119+
Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
120+
ACCESS EXCLUSIVE modes. This mode protects a table against
121+
concurrent updates.
122122
</para>
123123
</listitem>
124124
</varlistentry>
@@ -129,7 +129,7 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
129129
</term>
130130
<listitem>
131131

132-
<para>
132+
<para>
133133
Conflicts with ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
134134
EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is more
135135
restrictive than SHARE mode because of only one transaction
@@ -144,10 +144,10 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
144144
</term>
145145
<listitem>
146146

147-
<para>
147+
<para>
148148
Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
149149
EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is yet more
150-
restrictive than SHARE ROW EXCLUSIVE one -it blocks concurrent
150+
restrictive thanthat ofSHARE ROW EXCLUSIVE;it blocks all concurrent
151151
SELECT FOR UPDATE queries.
152152
</para>
153153
</listitem>
@@ -159,24 +159,24 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
159159
</term>
160160
<listitem>
161161
<note>
162-
<para>
163-
Automatically acquired by <command>ALTER TABLE</command>,
164-
<command>DROP TABLE</command>, <command>VACUUM</command> statements.
165-
</para>
166-
</note>
162+
<para>
163+
Automatically acquired by <command>ALTER TABLE</command>,
164+
<command>DROP TABLE</command>, <command>VACUUM</command> statements.
165+
</para>
166+
</note>
167167

168-
<para>
168+
<para>
169169
This is the most restrictive lock mode which conflicts with all other
170-
lock modes and protects locked table from any concurrent operations.
171-
</para>
170+
lock modes and protectsalocked table from any concurrent operations.
171+
</para>
172172

173-
<note>
174-
<para>
175-
This lock mode is also acquired byfirst form of
176-
<command>LOCK TABLE</command> (i.e. without explicit
177-
lock mode option).
178-
</para>
179-
</note>
173+
<note>
174+
<para>
175+
This lock mode is also acquired byan unqualified
176+
<command>LOCK TABLE</command> (i.e.the commandwithout an explicit
177+
lock mode option).
178+
</para>
179+
</note>
180180
</listitem>
181181
</varlistentry>
182182

@@ -218,92 +218,104 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
218218
Description
219219
</title>
220220
<para>
221-
<productname>Postgres</productname> always usesless restrictive
222-
lockmodes ever possible. <command>LOCK TABLE</command> statement
223-
provided for cases when you might needinmore restrictive locking.
221+
<productname>Postgres</productname> always usesthe least restrictive
222+
lockmode whenever possible. <command>LOCK TABLE</command>
223+
provided for cases when you might need more restrictive locking.
224224
</para>
225225

226226
<para>
227-
For example, application run transaction at READ COMMITTED isolation
228-
level and need to ensure existance data in a table for duration of
229-
transaction. To achieve this you could use SHARE lock mode over
227+
For example, an application runs a transaction at READ COMMITTED isolation
228+
level and needs to ensure the existance of data in a table for the
229+
duration of the
230+
transaction. To achieve this you could use SHARE lock mode over the
230231
table before querying. This will protect data from concurrent changes
231-
and provide your further read operations over table with data in their
232-
real current state, because of SHARE lock mode conflicts with ROW EXCLUSIVE
233-
one, acquired by writers, and your LOCK TABLE table IN SHARE MODE statement
234-
will wait untill concurrent write operations (if any) commit/rollback.
235-
(Note that to read data in their real current state running transaction
236-
at SERIALIZABLE isolation level you have to execute LOCK TABLE
237-
statement before execution any DML statement, when transaction defines
238-
what concurrent changes will be visible to herself).
232+
and provide any further read operations over the table with data in their
233+
actual current state, because SHARE lock mode conflicts with any ROW EXCLUSIVE
234+
one acquired by writers, and your LOCK TABLE table IN SHARE MODE statement
235+
will wait until any concurrent write operations commit or rollback.
236+
237+
<note>
238+
<para>
239+
To read data in their real current state when running a transaction
240+
at the SERIALIZABLE isolation level you have to execute a LOCK TABLE
241+
statement before execution any DML statement, when the transaction defines
242+
what concurrent changes will be visible to itself.
243+
</para>
244+
</note>
239245
</para>
240246

241247
<para>
242-
If, inaddition to requirements above, transaction is going to
248+
Inaddition totherequirements above, if a transaction is going to
243249
change data in a table then SHARE ROW EXCLUSIVE lock mode should
244250
be acquired to prevent deadlock conditions when two concurrent
245-
transactionswouldlock table in SHARE mode andthan would
251+
transactionsattempt tolockthetable in SHARE mode andthen
246252
try to change data in this table, both (implicitly) acquiring
247253
ROW EXCLUSIVE lock mode that conflicts with concurrent SHARE lock.
248254
</para>
249255

250256
<para>
251-
Following deadlock issue (when two transaction wait one another)
252-
touched above, you should follow two general rules to prevent
257+
To continue with the deadlock (when two transaction wait one another)
258+
issue raised above, you should follow two general rules to prevent
253259
deadlock conditions:
254260
</para>
255-
256-
<listitem>
257-
<para>
258-
Transactions have to acquire locks on the same objects in the same order.
259-
</para>
261+
262+
<itemizedlist>
263+
<listitem>
264+
<para>
265+
Transactions have to acquire locks on the same objects in the same order.
266+
</para>
260267

261-
<para>
262-
For example, if one application updates row R1 and than updates
263-
row R2 (in the same transaction) then second application shouldn't
264-
update row R2 if it's going update row R1 later (in single transaction).
265-
Instead, it should update R1 and R2rowsin the same order as first
266-
application.
267-
</para>
268-
</listitem>
268+
<para>
269+
For example, if one application updates row R1 and than updates
270+
row R2 (in the same transaction) then the second application shouldn't
271+
update row R2 if it's goingtoupdate row R1 later (in a single transaction).
272+
Instead, it should updaterowsR1 and R2 in the same order as the first
273+
application.
274+
</para>
275+
</listitem>
269276

270-
<listitem>
271-
<para>
272-
Transactions should acquire two conflicting lock modes only if
273-
one of them is self-conflicting (i.e. may be held by one
274-
transaction at time only) and should acquire most restrictive
275-
mode first.
276-
</para>
277+
<listitem>
278+
<para>
279+
Transactions should acquire two conflicting lock modes only if
280+
one of them is self-conflicting (i.e. may be held by one
281+
transaction at time only). If multiple lock modes are involved,
282+
then transactions should always acquire the most restrictivemode first.
283+
</para>
277284

278-
<para>
279-
Example for this rule is described above when told about using
280-
SHARE ROW EXCLUSIVE mode instead of SHARE one.
281-
</para>
282-
</listitem>
285+
<para>
286+
An example for this rule was given previously when discussing the
287+
use of SHARE ROW EXCLUSIVE mode rather than SHARE mode.
288+
</para>
289+
</listitem>
290+
</itemizedlist>
283291

284292
<note>
285293
<para>
286294
<productname>Postgres</productname> does detect deadlocks and will
287-
rollbackone ofwaitingtransactions to resolve the deadlock.
295+
rollbackat least onewaitingtransaction to resolve the deadlock.
288296
</para>
289297
</note>
290298

291299
<refsect2 id="R2-SQL-LOCK-3">
292300
<refsect2info>
293-
<date>1998-09-24</date>
301+
<date>1999-06-08</date>
294302
</refsect2info>
295303
<title>
296304
Notes
297305
</title>
306+
298307
<para>
299308
<command>LOCK</command> is a <productname>Postgres</productname>
300309
language extension.
301310
</para>
311+
302312
<para>
303313
Except for ACCESS SHARE/EXCLUSIVE lock modes, all other
304-
<productname>Postgres</productname> lock modes and
305-
<command>LOCK TABLE</command> syntax are compatible with
306-
<productname>Oracle</productname> ones.
314+
<productname>Postgres</productname> lock modes and the
315+
<command>LOCK TABLE</command> syntax are compatible with those
316+
present in <productname>Oracle</productname>.
317+
</para>
318+
307319
<para>
308320
<command>LOCK</command> works only inside transactions.
309321
</para>
@@ -329,7 +341,7 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
329341
-- Do ROLLBACK if record was not returned
330342
--
331343
INSERT INTO films_user_comments VALUES
332-
(_id_, 'GREAT! I was waitingit so long!');
344+
(_id_, 'GREAT! I was waitingfor it for so long!');
333345
COMMIT WORK;
334346
</programlisting>
335347
</para>
@@ -366,7 +378,8 @@ LOCK [ TABLE ] <replaceable class="PARAMETER">table</replaceable> IN SHARE ROW E
366378
<para>
367379
There is no <command>LOCK TABLE</command> in <acronym>SQL92</acronym>,
368380
which instead uses <command>SET TRANSACTION</command> to specify
369-
concurrency level on transactions. We support that too.
381+
concurrency level on transactions. We support that too; see
382+
<xref linkend="SQL-SET-TITLE" endterm="SQL-SET-TITLE"> for details.
370383
</para>
371384
</refsect2>
372385
</refsect1>

‎doc/src/sgml/ref/set.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
<refmiscinfo>SQL - Language Statements</refmiscinfo>
77
</refmeta>
88
<refnamediv>
9-
<refname>
9+
<refname id="SQL-SET-TITLE">
1010
SET
1111
</refname>
1212
<refpurpose>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp