grammar - src/backend/access/heap/README.tuplock

Started by Brad DeJongover 7 years ago2 messages
#1Brad DeJong
bpd0018@gmail.com
1 attachment(s)

The sentences in question currently read ...

Finally, SELECT FOR KEY SHARE obtains a shared lock which only
prevents tuple removal and modifications of key fields. This last mode
implements a mode just strong enough to implement RI checks, i.e. it ensures
that tuples do not go away from under a check, without blocking when some
other transaction that want to update the tuple without changing its key.

The last sentence is the problem, the first is just for context.

1) "This last mode implements a mode ..." seems awkward and the term "mode"
is not used to describe the other 3 levels of tuple locking strength. The
phrasing
used for SELECT FOR UPDATE ("This is the lock level that ...") is better.

2) noun/verb agreement
... transaction that want ...
should be either
... transaction that wants ... or ... transactions that want ...

3) mismatched clauses
... without blocking when ... transactions that want ...
should be either
... without blocking ... transactions that want ...
or
... without blocking when ... transactions want ...

The first says that our transaction's shared lock is not blocking other
transactions.

4) the "some other" in "some other transaction" just seems unnecessary.

Putting it all together, the attached patch changes the last sentence to ...

This lock level is just strong enough to implement RI checks, i.e. it
ensures
that tuples do not go away from under a check, without blocking transactions
that want to update the tuple without changing its key.

Attachments:

README.tuplock.patchapplication/octet-stream; name=README.tuplock.patchDownload
diff --git a/src/backend/access/heap/README.tuplock b/src/backend/access/heap/README.tuplock
index 10b8d78..b2f3a4c 100644
--- a/src/backend/access/heap/README.tuplock
+++ b/src/backend/access/heap/README.tuplock
@@ -45,10 +45,10 @@ and modifications which might alter the tuple's key. This is the lock that is
 implicitly taken by UPDATE operations which leave all key fields unchanged.
 SELECT FOR SHARE obtains a shared lock which prevents any kind of tuple
 modification. Finally, SELECT FOR KEY SHARE obtains a shared lock which only
-prevents tuple removal and modifications of key fields. This last mode
-implements a mode just strong enough to implement RI checks, i.e. it ensures
-that tuples do not go away from under a check, without blocking when some
-other transaction that want to update the tuple without changing its key.
+prevents tuple removal and modifications of key fields. This lock level is
+just strong enough to implement RI checks, i.e. it ensures that tuples do not
+go away from under a check, without blocking transactions that want to update
+the tuple without changing its key.
 
 The conflict table is:
 
#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Brad DeJong (#1)
Re: grammar - src/backend/access/heap/README.tuplock

I agree with all you say here; these were all my mistakes. Pushed
patch, thanks.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services