diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index b4ea227..e174a52 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9257,7 +9257,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
       <filename>postgresql.conf</filename> without restarting the server.
       They can also be set for a particular session in the connection request
       packet (for example, via <application>libpq</>'s <literal>PGOPTIONS</>
-      environment variable); any user can make such a change for his session.
+      environment variable); any user can make such a change for his or her session.
       However, these settings never change in a session after it is started.
       If you change them in <filename>postgresql.conf</filename>, send a
       <systemitem>SIGHUP</systemitem> signal to the postmaster to cause it to
@@ -9286,7 +9286,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
      <para>
       These settings can be set from <filename>postgresql.conf</filename>,
       or within a session via the <command>SET</> command.  Any user is
-      allowed to change his session-local value.  Changes in
+      allowed to change a session-local value.  Changes in
       <filename>postgresql.conf</filename> will affect existing sessions
       only if no session-local value has been established with <command>SET</>.
      </para>
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index ba04bdf..c0e5aae 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -692,7 +692,7 @@ local   db1,db2,@demodbs  all                                   md5
   <para>
    When using an external authentication system like Ident or GSSAPI,
    the name of the operating system user that initiated the connection
-   might not be the same as the database user he needs to connect as.
+   might not be the same as the database user it needs to connect as.
    In this case, a user name map can be applied to map the operating system
    user name to a database user.  To use user name mapping, specify
    <literal>map</literal>=<replaceable>map-name</replaceable>
@@ -1185,7 +1185,7 @@ omicron         bryanh                  guest1
     The drawback of this procedure is that it depends on the integrity
     of the client: if the client machine is untrusted or compromised,
     an attacker could run just about any program on port 113 and
-    return any user name he chooses. This authentication method is
+    return any user name he or she chooses. This authentication method is
     therefore only appropriate for closed networks where each client
     machine is under tight control and where the database and system
     administrators operate in close contact. In other words, you must
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index af1bda6..505b332 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1492,8 +1492,8 @@ REVOKE ALL ON accounts FROM PUBLIC;
    <command>DROP</>, <command>GRANT</>, <command>REVOKE</>, etc.)
    are always implicit in being the owner,
    and cannot be granted or revoked.  But the object owner can choose
-   to revoke his own ordinary privileges, for example to make a
-   table read-only for himself as well as others.
+   to revoke his or her own ordinary privileges, for example to make a
+   table read-only for him- or herself as well as others.
   </para>
 
   <para>
@@ -1819,7 +1819,7 @@ UPDATE 1
    example, both <literal>schema1</> and <literal>myschema</> can
    contain tables named <literal>mytable</>.  Unlike databases,
    schemas are not rigidly separated: a user can access objects in any
-   of the schemas in the database he is connected to, if he has
+   of the schemas in the database he or she is connected to, given the
    privileges to do so.
   </para>
 
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index 78ec509..7f1c506 100644
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -155,9 +155,9 @@ createdb <replaceable class="parameter">dbname</replaceable>
   </note>
 
   <para>
-   Sometimes you want to create a database for someone else, and have him
-   become the owner of the new database, so he can
-   configure and manage it himself.  To achieve that, use one of the
+   Sometimes you want to create a database for someone else, and have that person
+   become the owner of the new database, so he or she can
+   configure and manage it.  To achieve that, use one of the
    following commands:
 <programlisting>
 CREATE DATABASE <replaceable>dbname</> OWNER <replaceable>rolename</>;
diff --git a/doc/src/sgml/nls.sgml b/doc/src/sgml/nls.sgml
index 3adc1a4..1d33147 100644
--- a/doc/src/sgml/nls.sgml
+++ b/doc/src/sgml/nls.sgml
@@ -115,7 +115,7 @@ msgstr "another translated"
     for the translator, such as about expected alignment.  The #:
     comment indicates the exact location(s) where the message is used
     in the source.  The translator need not look at the program
-    source, but he can if there is doubt about the correct
+    source, but can if there is doubt about the correct
     translation.  The #, comments contain flags that describe the
     message in some way.  There are currently two flags:
     <literal>fuzzy</literal> is set if the message has possibly been
diff --git a/doc/src/sgml/ref/alter_user_mapping.sgml b/doc/src/sgml/ref/alter_user_mapping.sgml
index 3cd51b1..79f4a15 100644
--- a/doc/src/sgml/ref/alter_user_mapping.sgml
+++ b/doc/src/sgml/ref/alter_user_mapping.sgml
@@ -38,7 +38,7 @@ ALTER USER MAPPING FOR { <replaceable class="parameter">user_name</replaceable>
   <para>
    The owner of a foreign server can alter user mappings for that
    server for any user.  Also, a user can alter a user mapping for
-   his own user name if <literal>USAGE</> privilege on the server has
+   his or her own user name if <literal>USAGE</> privilege on the server has
    been granted to the user.
   </para>
  </refsect1>
diff --git a/doc/src/sgml/ref/create_schema.sgml b/doc/src/sgml/ref/create_schema.sgml
index 79305f1..02248cb 100644
--- a/doc/src/sgml/ref/create_schema.sgml
+++ b/doc/src/sgml/ref/create_schema.sgml
@@ -205,7 +205,7 @@ CREATE VIEW hollywood.winners AS
    all objects within it.  <productname>PostgreSQL</productname>
    allows schemas to contain objects owned by users other than the
    schema owner.  This can happen only if the schema owner grants the
-   <literal>CREATE</> privilege on his schema to someone else, or a
+   <literal>CREATE</> privilege on the schema to someone else, or a
    superuser chooses to create objects in it.
   </para>
 
diff --git a/doc/src/sgml/ref/create_user_mapping.sgml b/doc/src/sgml/ref/create_user_mapping.sgml
index bb0c9c0..806163b 100644
--- a/doc/src/sgml/ref/create_user_mapping.sgml
+++ b/doc/src/sgml/ref/create_user_mapping.sgml
@@ -41,7 +41,7 @@ CREATE USER MAPPING FOR { <replaceable class="parameter">user_name</replaceable>
   <para>
    The owner of a foreign server can create user mappings for that
    server for any user.  Also, a user can create a user mapping for
-   his own user name if <literal>USAGE</> privilege on the server has
+   his or her own user name if <literal>USAGE</> privilege on the server has
    been granted to the user.
   </para>
  </refsect1>
diff --git a/doc/src/sgml/ref/drop_schema.sgml b/doc/src/sgml/ref/drop_schema.sgml
index 859f17e..dbdb4fc 100644
--- a/doc/src/sgml/ref/drop_schema.sgml
+++ b/doc/src/sgml/ref/drop_schema.sgml
@@ -35,7 +35,7 @@ DROP SCHEMA [ IF EXISTS ] <replaceable class="PARAMETER">name</replaceable> [, .
   <para>
    A schema can only be dropped by its owner or a superuser.  Note that
    the owner can drop the schema (and thereby all contained objects)
-   even if he does not own some of the objects within the schema.
+   even if he or she does not own some of the objects within the schema.
   </para>
  </refsect1>
 
diff --git a/doc/src/sgml/ref/drop_user_mapping.sgml b/doc/src/sgml/ref/drop_user_mapping.sgml
index ddfad0b..e82ac01 100644
--- a/doc/src/sgml/ref/drop_user_mapping.sgml
+++ b/doc/src/sgml/ref/drop_user_mapping.sgml
@@ -35,7 +35,7 @@ DROP USER MAPPING [ IF EXISTS ] FOR { <replaceable class="parameter">user_name</
 
   <para>
    The owner of a foreign server can drop user mappings for that server
-   for any user.  Also, a user can drop a user mapping for his own
+   for any user.  Also, a user can drop a user mapping for his or her own
    user name if <literal>USAGE</> privilege on the server has been
    granted to the user.
   </para>
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index d9ac8d2..0dd3b01 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -141,7 +141,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
    There is no need to grant privileges to the owner of an object
    (usually the user that created it),
    as the owner has all privileges by default.  (The owner could,
-   however, choose to revoke some of his own privileges for safety.)
+   however, choose to revoke some privileges for safety.)
   </para>
 
   <para>
@@ -365,7 +365,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
       </para>
       <para>
        For servers, this privilege enables the grantee to create foreign
-       tables using the server, and also to create, alter, or drop his own
+       tables using the server, and also to create, alter, or drop his or her own
        user's user mappings associated with that server.
       </para>
      </listitem>
@@ -438,7 +438,7 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
 
    <para>
     A user may perform <command>SELECT</>, <command>INSERT</>, etc. on a
-    column if he holds that privilege for either the specific column or
+    column if he or she holds that privilege for either the specific column or
     its whole table.  Granting the privilege at the table level and then
     revoking it for one column will not do what you might wish: the
     table-level grant is unaffected by a column-level operation.
@@ -628,12 +628,12 @@ GRANT admins TO joe;
    <para>
     <productname>PostgreSQL</productname> allows an object owner to revoke his
     own ordinary privileges: for example, a table owner can make the table
-    read-only to himself by revoking his own <literal>INSERT</>,
+    read-only to him- or herself by revoking the <literal>INSERT</>,
     <literal>UPDATE</>, <literal>DELETE</>, and <literal>TRUNCATE</>
     privileges.  This is not possible according to the SQL standard.  The
     reason is that <productname>PostgreSQL</productname> treats the owner's
-    privileges as having been granted by the owner to himself; therefore he
-    can revoke them too.  In the SQL standard, the owner's privileges are
+    privileges as having been granted by the owner to him- or herself; therefore they
+    can be revoked too.  In the SQL standard, the owner's privileges are
     granted by an assumed entity <quote>_SYSTEM</>.  Not being
     <quote>_SYSTEM</>, the owner cannot revoke these rights.
    </para>
diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml
index 36c286b..12c5b35 100644
--- a/doc/src/sgml/ref/revoke.sgml
+++ b/doc/src/sgml/ref/revoke.sgml
@@ -193,7 +193,7 @@ REVOKE [ ADMIN OPTION FOR ]
    Instead, user A could revoke the grant option from user B and use
    the <literal>CASCADE</literal> option so that the privilege is
    in turn revoked from user C.  For another example, if both A and B
-   have granted the same privilege to C, A can revoke his own grant
+   have granted the same privilege to C, A can revoke his or her own grant
    but not B's grant, so C will still effectively have the privilege.
   </para>
 
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index fe72fe8..fa6e785e 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -2024,13 +2024,13 @@ SELECT * FROM shoelace;
     are used due to rules get checked against the
     privileges of the rule owner, not the user invoking the rule.
     This means that a user only needs the required privileges
-    for the tables/views that he names explicitly in his queries.
+    for the tables/views that he or she names explicitly in queries.
 </para>
 
 <para>
-    For example: A user has a list of phone numbers where some of
+    For example: A user <literal>u</literal> has a list of phone numbers where some of
     them are private, the others are of interest for the secretary of the office.
-    He can construct the following:
+    <literal>u</literal> can construct the following:
 
 <programlisting>
 CREATE TABLE phone_data (person text, phone text, private boolean);
@@ -2040,15 +2040,15 @@ CREATE VIEW phone_number AS
 GRANT SELECT ON phone_number TO secretary;
 </programlisting>
 
-    Nobody except him (and the database superusers) can access the
+    Nobody except <literal>u</literal> (and the database superusers) can access the
     <literal>phone_data</> table. But because of the <command>GRANT</>,
-    the secretary can run a <command>SELECT</command> on the
+    <literal>secretary</literal> can run a <command>SELECT</command> on the
     <literal>phone_number</> view. The rule system will rewrite the
     <command>SELECT</command> from <literal>phone_number</> into a
     <command>SELECT</command> from <literal>phone_data</>.
     Since the user is the owner of
     <literal>phone_number</> and therefore the owner of the rule, the
-    read access to <literal>phone_data</> is now checked against his
+    read access to <literal>phone_data</> is now checked against <literal>u</literal>'s
     privileges and the query is permitted. The check for accessing
     <literal>phone_number</> is also performed, but this is done
     against the invoking user, so nobody but the user and the
@@ -2056,24 +2056,24 @@ GRANT SELECT ON phone_number TO secretary;
 </para>
 
 <para>
-    The privileges are checked rule by rule. So the secretary is for now the
-    only one who can see the public phone numbers. But the secretary can setup
+    The privileges are checked rule by rule. So <literal>secretary</literal> is for now the
+    only one who can see the public phone numbers. But <literal>secretary</literal> can setup
     another view and grant access to that to the public. Then, anyone
-    can see the <literal>phone_number</> data through the secretary's view.
-    What the secretary cannot do is to create a view that directly
-    accesses <literal>phone_data</>.  (Actually he can, but it will not work since
+    can see the <literal>phone_number</> data through <literal>secretary</literal>'s view.
+    What <literal>secretary</literal> cannot do is to create a view that directly
+    accesses <literal>phone_data</>.  (Actually <literal>secretary</literal> can, but it will not work since
     every access will be denied during the permission checks.)
-    And as soon as the user will notice, that the secretary opened
-    his <literal>phone_number</> view, he can revoke his access. Immediately, any
-    access to the secretary's view would fail.
+    And as soon as the user notices that <literal>secretary</literal> opened
+    the <literal>phone_number</> view, <literal>u</literal> can revoke <literal>secretary</literal>'s access. Immediately, any
+    access to <literal>secretary</literal>'s view would fail.
 </para>
 
 <para>
     One might think that this rule-by-rule checking is a security
-    hole, but in fact it isn't.   But if it did not work this way, the secretary
+    hole, but in fact it isn't.   But if it did not work this way, <literal>secretary</literal>
     could set up a table with the same columns as <literal>phone_number</> and
-    copy the data to there once per day. Then it's his own data and
-    he can grant access to everyone he wants. A
+    copy the data to there once per day. Then it's <literal>secretary</literal>'s own data and
+    he or she can grant access to anyone. A
     <command>GRANT</command> command means, <quote>I trust you</quote>.
     If someone you trust does the thing above, it's time to
     think it over and then use <command>REVOKE</command>.
@@ -2124,8 +2124,8 @@ SELECT * FROM phone_number WHERE tricky(person, phone);
     the <literal>shoelace</> view to someone else, but only
     <literal>SELECT</> on <literal>shoelace_log</>. The rule action to
     write log entries will still be executed successfully, and that
-    other user could see the log entries.  But he cannot create fake
-    entries, nor could he manipulate or remove existing ones.  In this
+    other user could see the log entries.  But he or she cannot create fake
+    entries, nor manipulate or remove existing ones.  In this
     case, there is no possibility of subverting the rules by convincing
     the planner to alter the order of operations, because the only rule
     which references <literal>shoelace_log</> is an unqualified
diff --git a/doc/src/sgml/sslinfo.sgml b/doc/src/sgml/sslinfo.sgml
index 22ef439..7e602b9 100644
--- a/doc/src/sgml/sslinfo.sgml
+++ b/doc/src/sgml/sslinfo.sgml
@@ -96,7 +96,7 @@
      Returns serial number of current client certificate.  The combination of
      certificate serial number and certificate issuer is guaranteed to
      uniquely identify a certificate (but not its owner &mdash; the owner
-     ought to regularly change his keys, and get new certificates from the
+     ought to regularly change the keys, and get new certificates from the
      issuer).
     </para>
 
diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index 342fdad..14b4d02 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -143,7 +143,7 @@
 
    <para>
     Possibly, your site administrator has already created a database
-    for your use.  He should have told you what the name of your
+    for your use and told you what the name of your
     database is.  In that case you can omit this step and skip ahead
     to the next section.
    </para>
diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml
index 68220bf..f96ef1d 100644
--- a/doc/src/sgml/xplang.sgml
+++ b/doc/src/sgml/xplang.sgml
@@ -49,7 +49,7 @@
     <literal>template1</> will be copied by <command>CREATE DATABASE</>.
     So the database administrator can
     decide which languages are available in which databases and can make
-    some languages available by default if he chooses.
+    some languages available by default if he or she chooses.
    </para>
 
    <para>
