Grammar, my boy, grammar :-(

diff --git a/doc/src/sgml/ref/notify.sgml b/doc/src/sgml/ref/notify.sgml
index 92310c0d8ce82e727639c56f27dfb1ecf74c797b..0404de2c308a74755b52defd0864c9b27dd3ba83 100644 (file)
--- a/doc/src/sgml/ref/notify.sgml
+++ b/doc/src/sgml/ref/notify.sgml
@@ -147,16 +147,16 @@ after the transaction is completed (either committed or aborted).  Again, the
 reasoning is that if a notify were delivered within a transaction that was
 later aborted, one would want the notification to be undone somehow --- but
 the backend cannot "take back" a notify once it has sent it to the frontend.
-So notify events are delivered only between transactions.  The upshot of this
+So notify events are only delivered between transactions.  The upshot of this
 is that applications using NOTIFY for real-time signaling
 should try to keep their transactions short.
 
 
-NOTIFY behaves rather like Unix signals in one important
-respect: if the same notify name is signaled multiple times in quick
+NOTIFY behaves like Unix signals in one important
+respect: if the same condition name is signaled multiple times in quick
 succession, recipients may get only one notify event for several executions
 of NOTIFY.  So it is a bad idea to depend on the number
-of notifies received; instead use NOTIFY to wake up
+of notifies received.  Instead, use NOTIFY to wake up
 applications that need to pay attention to something, and use a database
 object (such as a sequence) to keep track of what happened or how many times
 it happened.
@@ -201,8 +201,8 @@ table name, even if syntactically valid as a name.  That is no longer required.
 
 
 In Postgres releases prior to 6.4, the backend
-PID delivered in a notify message is always the PID of the frontend's own
-backend.  So it is not possible to distinguish one's own notifies from other
+PID delivered in a notify message was always the PID of the frontend's own
+backend.  So it was not possible to distinguish one's own notifies from other
 clients' notifies in those earlier releases.