Hi,

While working on unrelated documentation change, I noticed some
trailing whitespaces in various documentation files.  PFA a simple
patch to get rid of them (I didn't removed the one corresponding to
psql output), if that helps.
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 45a3cf3def..ffed887ab7 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -671,7 +671,7 @@ hostnogssenc <replaceable>database</replaceable>  <replaceable>user</replaceable
    non-null <structfield>error</structfield> fields indicate problems in the
    corresponding lines of the file.
   </para>
- 
+
   <tip>
    <para>
     To connect to a particular database, a user must not only pass the
@@ -747,9 +747,9 @@ host    all             all             .example.com            scram-sha-256
 # reject all connections from 192.168.54.1 (since that entry will be
 # matched first), but allow GSSAPI-encrypted connections from anywhere else
 # on the Internet.  The zero mask causes no bits of the host IP address to
-# be considered, so it matches any host.  Unencrypted GSSAPI connections 
+# be considered, so it matches any host.  Unencrypted GSSAPI connections
 # (which "fall through" to the third line since "hostgssenc" only matches
-# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.  
+# encrypted GSSAPI connections) are allowed, but only from 192.168.12.10.
 #
 # TYPE  DATABASE        USER            ADDRESS                 METHOD
 host    all             all             192.168.54.1/32         reject
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d2da1abe61..75f9471ff6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -953,7 +953,7 @@ include_dir 'conf.d'
         This parameter is supported only on systems that support
         <symbol>TCP_USER_TIMEOUT</symbol>; on other systems, it must be zero.
         In sessions connected via a Unix-domain socket, this parameter is
-        ignored and always reads as zero. 
+        ignored and always reads as zero.
        </para>
        <note>
         <para>
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index d5ee6a58e7..1bd7cf4ebd 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -312,7 +312,7 @@ current=testdb1 (should be testdb1)
   </para>
 
   <para>
-   The third option is to declare a sql identifier linked to 
+   The third option is to declare a sql identifier linked to
    the connection, for example:
 <programlisting>
 EXEC SQL AT <replaceable>connection-name</replaceable> DECLARE <replaceable>statement-name</replaceable> STATEMENT;
@@ -558,7 +558,7 @@ EXEC SQL COMMIT;
        </para>
       </listitem>
      </varlistentry>
-     
+
      <varlistentry>
       <term><literal>EXEC SQL SET AUTOCOMMIT TO ON</literal></term>
       <listitem>
@@ -6843,7 +6843,7 @@ EXEC SQL [ AT <replaceable class="parameter">connection_name</replaceable> ] DEC
         A database connection name established by the <command>CONNECT</command> command.
        </para>
        <para>
-        If AT clause is omitted, an SQL statement identifier is associated with the DEFAULT connection.   
+        If AT clause is omitted, an SQL statement identifier is associated with the DEFAULT connection.
        </para>
       </listitem>
      </varlistentry>
@@ -6862,10 +6862,10 @@ EXEC SQL [ AT <replaceable class="parameter">connection_name</replaceable> ] DEC
    </refsect1>
 
    <refsect1>
-    <title>Notes</title>    
+    <title>Notes</title>
     <para>
      AT clause can be used at other dynamic SQL statements. The following table
-     gives the connected database when AT clause is used at DECLARE STATEMENT 
+     gives the connected database when AT clause is used at DECLARE STATEMENT
      and other dynamic statements.
     </para>
     <table tocentry="1" id="ecpg-declare-statement-table">
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5c3724ab9e..6211ff3927 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17397,7 +17397,7 @@ SET search_path TO <replaceable>schema</replaceable> <optional>, <replaceable>sc
     because it needs access to the predicate lock manager's shared
     state for a short time.
    </para>
-   
+
    <indexterm>
     <primary>version</primary>
    </indexterm>
@@ -21225,7 +21225,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
       <row><entry>Name</entry> <entry>Return Type</entry> <entry>Description</entry></row>
      </thead>
 
-     <tbody> 
+     <tbody>
       <row>
        <entry>
         <indexterm><primary>pg_partition_tree</primary></indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 2b4dcd03c8..543691dad4 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1518,7 +1518,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
     processing would request a file from the WAL archive, reporting failure
     if the file was unavailable.  For standby processing it is normal for
     the next WAL file to be unavailable, so the standby must wait for
-    it to appear. For files ending in 
+    it to appear. For files ending in
     <literal>.history</literal> there is no need to wait, and a non-zero return
     code must be returned. A waiting <varname>restore_command</varname> can be
     written as a custom script that loops after polling for the existence of
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index 3e0e92a785..8c5df6f0bb 100644
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -625,7 +625,7 @@ SELECT jdoc-&gt;'guid', jdoc-&gt;'name' FROM api WHERE jdoc @&gt; '{"tags": ["qu
  </sect2>
 
  <sect2 id="datatype-jsonpath">
-  <title>jsonpath Type</title> 
+  <title>jsonpath Type</title>
 
   <indexterm zone="datatype-jsonpath">
    <primary>jsonpath</primary>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 4eb43f2de9..9cc332b6ad 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -3622,7 +3622,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
        with write locks that can potentially see the table to finish.
        This phase is skipped when not in concurrent mode.
        Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
-       and <structname>current_locker_pid</structname> contain the progress 
+       and <structname>current_locker_pid</structname> contain the progress
        information for this phase.
       </entry>
      </row>
@@ -3644,7 +3644,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
        with write locks that can potentially write into the table to finish.
        This phase is skipped when not in concurrent mode.
        Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
-       and <structname>current_locker_pid</structname> contain the progress 
+       and <structname>current_locker_pid</structname> contain the progress
        information for this phase.
       </entry>
      </row>
@@ -3682,7 +3682,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
        that can potentially see the table to release their snapshots.  This
        phase is skipped when not in concurrent mode.
        Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
-       and <structname>current_locker_pid</structname> contain the progress 
+       and <structname>current_locker_pid</structname> contain the progress
        information for this phase.
       </entry>
      </row>
@@ -3693,7 +3693,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
        with read locks on the table to finish, before marking the old index dead.
        This phase is skipped when not in concurrent mode.
        Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
-       and <structname>current_locker_pid</structname> contain the progress 
+       and <structname>current_locker_pid</structname> contain the progress
        information for this phase.
       </entry>
      </row>
@@ -3704,7 +3704,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
        with read locks on the table to finish, before dropping the old index.
        This phase is skipped when not in concurrent mode.
        Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
-       and <structname>current_locker_pid</structname> contain the progress 
+       and <structname>current_locker_pid</structname> contain the progress
        information for this phase.
       </entry>
      </row>
@@ -3725,8 +3725,8 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
    that will be reported and provide information about how to interpret it.
    Progress for <command>VACUUM FULL</command> commands is reported via
    <structname>pg_stat_progress_cluster</structname>
-   because both <command>VACUUM FULL</command> and <command>CLUSTER</command> 
-   rewrite the table, while regular <command>VACUUM</command> only modifies it 
+   because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
+   rewrite the table, while regular <command>VACUUM</command> only modifies it
    in place. See <xref linkend='cluster-progress-reporting'/>.
   </para>
 
@@ -3912,7 +3912,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
   <para>
    Whenever <command>CLUSTER</command> or <command>VACUUM FULL</command> is
    running, the <structname>pg_stat_progress_cluster</structname> view will
-   contain a row for each backend that is currently running either command. 
+   contain a row for each backend that is currently running either command.
    The tables below describe the information that will be reported and
    provide information about how to interpret it.
   </para>
@@ -4054,7 +4054,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
     <row>
      <entry><literal>sorting tuples</literal></entry>
      <entry>
-       <command>CLUSTER</command> is currently sorting tuples. 
+       <command>CLUSTER</command> is currently sorting tuples.
      </entry>
     </row>
     <row>
@@ -4072,7 +4072,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
     <row>
      <entry><literal>performing final cleanup</literal></entry>
      <entry>
-       The command is performing final cleanup.  When this phase is 
+       The command is performing final cleanup.  When this phase is
        completed, <command>CLUSTER</command>
        or <command>VACUUM FULL</command> will end.
      </entry>
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index b0b03c54e5..af5d48a5c7 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -102,7 +102,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     order-preserving merge.  In contrast, <literal>Gather</literal> reads tuples
     from the workers in whatever order is convenient, destroying any sort
     order that may have existed.
-   </para>   
+   </para>
  </sect1>
 
  <sect1 id="when-can-parallel-query-be-used">
@@ -347,7 +347,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
     workers in order to produce the final result.  This is reflected in the
     plan as a <literal>Finalize Aggregate</literal> node.
   </para>
-  
+
   <para>
     Because the <literal>Finalize Aggregate</literal> node runs on the leader
     process, queries which produce a relatively large number of groups in
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 54b5e98a0e..a46fd750f6 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -544,7 +544,7 @@
 
   <para>
    <filename>postgres_fdw</filename> likewise establishes remote session settings
-   for various parameters: 
+   for various parameters:
    <itemizedlist spacing="compact">
     <listitem>
      <para>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index a0e1f78bfc..09893d96b5 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1586,7 +1586,7 @@ PostgreSQL is <literal>tls-server-end-point</literal>.
    user-supplied password in the transmitted password hash.  While this
    prevents the password hash from being successfully retransmitted in
    a later session, it does not prevent a fake server between the real
-   server and client from passing through the server's random value 
+   server and client from passing through the server's random value
    and successfully authenticating.
   </para>
 
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index dd6bce57d2..830e87fc6a 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -327,7 +327,7 @@ PostgreSQL documentation
            </para>
            <para>
             When tar format mode is used, the write-ahead log files will be
-            written to a separate file named <filename>pg_wal.tar</filename> 
+            written to a separate file named <filename>pg_wal.tar</filename>
             (if the server is a version earlier than 10, the file will be named
             <filename>pg_xlog.tar</filename>).
            </para>
diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index e9715d5cf7..4d91eeb0ff 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -260,7 +260,7 @@ GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind
 GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
 GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
 GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;
-</programlisting>  
+</programlisting>
   </para>
 
   <para>
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index c896882dd1..f6d423ee13 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -796,7 +796,7 @@ psql --username=postgres --file=script.sql postgres
    In <productname>PostgreSQL</productname> 12 and later small tables by
    default don't have a free space map, as a space optimization.  If you are
    upgrading a pre-12 cluster, the free space maps of small tables will
-   likewise not be transferred to the new cluster.  
+   likewise not be transferred to the new cluster.
   </para>
 
  </refsect1>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index fde9dbc134..388dc7e966 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -643,7 +643,7 @@ psql: could not connect to server: No such file or directory
     amount of anonymous <function>mmap</function> shared memory.
     Alternatively, a single large System V shared memory region can be used
     (see <xref linkend="guc-shared-memory-type"/>).
-    
+
     In addition a significant number of semaphores, which can be either
     System V or POSIX style, are created at server startup.  Currently,
     POSIX semaphores are used on Linux and FreeBSD systems while other
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index 126d1f6c15..d43ef13919 100644
--- a/doc/src/sgml/spgist.sgml
+++ b/doc/src/sgml/spgist.sgml
@@ -160,7 +160,7 @@
       </entry>
       <entry>
         <literal>&lt;-&gt;</literal>
-      </entry>      
+      </entry>
      </row>
      <row>
       <entry><literal>text_ops</literal></entry>

Reply via email to