postgres
diff --git a/‎doc/src/sgml/event-trigger.sgml
Copy file name to clipboardExpand all lines: doc/src/sgml/event-trigger.sgml
+5-5Lines changed: 5 additions & 5 deletions b/‎doc/src/sgml/event-trigger.sgml
Copy file name to clipboardExpand all lines: doc/src/sgml/event-trigger.sgml
+5-5Lines changed: 5 additions & 5 deletions
diff --git a/‎src/backend/commands/event_trigger.c
Copy file name to clipboardExpand all lines: src/backend/commands/event_trigger.c
+9-9Lines changed: 9 additions & 9 deletions b/‎src/backend/commands/event_trigger.c
Copy file name to clipboardExpand all lines: src/backend/commands/event_trigger.c
+9-9Lines changed: 9 additions & 9 deletions
@@ -39,18 +39,18 @@
    <para>
      The <literal>login</literal> event occurs when an authenticated user logs
      into the system. Any bug in a trigger procedure for this event may
-     prevent successful login to the system. Such bugs may be fixed by
-     setting <xref linkend="guc-event-triggers"/> is set to <literal>false</literal>
-     either in a connection string or configuration file. Alternative is
-     restarting the system in single-user mode (as event triggers are
+     prevent successful login to the system. Such bugs may be worked around by
+     setting <xref linkend="guc-event-triggers"/> to <literal>false</literal>
+     either in a connection string or configuration file. Alternatively, you can
+     restart the system in single-user mode (as event triggers are
      disabled in this mode). See the <xref linkend="app-postgres"/> reference
      page for details about using single-user mode.
      The <literal>login</literal> event will also fire on standby servers.
      To prevent servers from becoming inaccessible, such triggers must avoid
      writing anything to the database when running on a standby.
      Also, it's recommended to avoid long-running queries in
      <literal>login</literal> event triggers.  Note that, for instance,
-     canceling connection in <application>psql</application> wouldn't cancel
+     canceling a connection in <application>psql</application> will not cancel
      the in-progress <literal>login</literal> trigger.
    </para>
 
 
@@ -174,7 +174,7 @@ CreateEventTrigger(CreateEventTrigStmt *stmt)
 	else if (strcmp(stmt->eventname, "login") == 0 && tags != NULL)
 		ereport(ERROR,
 				(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
-				 errmsg("tag filtering is not supported for login event trigger")));
+				 errmsg("tag filtering is not supported for login event triggers")));
 
 	/*
 	 * Give user a nice error message if an event trigger of the same name
@@ -307,7 +307,7 @@ insert_event_trigger_tuple(const char *trigname, const char *eventname, Oid evtO
 	heap_freetuple(tuple);
 
 	/*
-	 * Login event triggers have an additional flag in pg_database to avoid
+	 * Login event triggers have an additional flag in pg_database to enable
 	 * faster lookups in hot codepaths. Set the flag unless already True.
 	 */
 	if (strcmp(eventname, "login") == 0)
@@ -376,7 +376,7 @@ filter_list_to_array(List *filterlist)
 
 /*
  * Set pg_database.dathasloginevt flag for current database indicating that
- * current database has on login triggers.
+ * current database has on login event triggers.
  */
 void
 SetDatatabaseHasLoginEventTriggers(void)
@@ -444,7 +444,7 @@ AlterEventTrigger(AlterEventTrigStmt *stmt)
 	CatalogTupleUpdate(tgrel, &tup->t_self, tup);
 
 	/*
-	 * Login event triggers have an additional flag in pg_database to avoid
+	 * Login event triggers have an additional flag in pg_database to enable
 	 * faster lookups in hot codepaths. Set the flag unless already True.
 	 */
 	if (namestrcmp(&evtForm->evtevent, "login") == 0 &&
@@ -695,7 +695,7 @@ EventTriggerCommonSetup(Node *parsetree,
 		}
 	}
 
-	/* don't spend any more time on this if no functions to run */
+	/* Don't spend any more time on this if no functions to run */
 	if (runlist == NIL)
 		return NIL;
 
@@ -878,7 +878,7 @@ EventTriggerSQLDrop(Node *parsetree)
 
 /*
  * Fire login event triggers if any are present.  The dathasloginevt
- * pg_database flag is left when an event trigger is dropped, to avoid
+ * pg_database flag is left unchanged when an event trigger is dropped to avoid
  * complicating the codepath in the case of multiple event triggers.  This
  * function will instead unset the flag if no trigger is defined.
  */
@@ -891,7 +891,7 @@ EventTriggerOnLogin(void)
 	/*
 	 * See EventTriggerDDLCommandStart for a discussion about why event
 	 * triggers are disabled in single user mode or via a GUC.  We also need a
-	 * database connection (some background workers doesn't have it).
+	 * database connection (some background workers don't have it).
 	 */
 	if (!IsUnderPostmaster || !event_triggers ||
 		!OidIsValid(MyDatabaseId) || !MyDatabaseHasLoginEventTriggers)
@@ -920,7 +920,7 @@ EventTriggerOnLogin(void)
 
 	/*
 	 * There is no active login event trigger, but our
-	 * pg_database.dathasloginevt was set. Try to unset this flag.  We use the
+	 * pg_database.dathasloginevt is set. Try to unset this flag.  We use the
 	 * lock to prevent concurrent SetDatatabaseHasLoginEventTriggers(), but we
 	 * don't want to hang the connection waiting on the lock.  Thus, we are
 	 * just trying to acquire the lock conditionally.
@@ -931,7 +931,7 @@ EventTriggerOnLogin(void)
 		/*
 		 * The lock is held.  Now we need to recheck that login event triggers
 		 * list is still empty.  Once the list is empty, we know that even if
-		 * there is a backend, which concurrently inserts/enables login
+		 * there is a backend which concurrently inserts/enables a login event
 		 * trigger, it will update pg_database.dathasloginevt *afterwards*.
 		 */
 		runlist = EventTriggerCommonSetup(NULL,