Fix missnamed pid columns in queries

The procpid attribute in the pg_stat_activity and pg_stat_replication
views has been renamed to just pid, but a few queries in the docs and
alternative test outputs hadn't gotten the memo.

Reported-by: Craig Sylvester
Reviewed-by: David Yozie

gpdb-doc/dita/admin_guide/managing/highavail.xml

@@ -242,7 +242,7 @@ mirror3=3:sdw2:sdw2-2:52002:53002:54002:/gpdata/mir1/gp3
             pg_stat_replication. The view lists information about the <codeph>walsender</codeph>
             process that is used for Greenplum Database master mirroring. For example, this command
             displays the process ID and state of the <codeph>walsender</codeph> process:</p>
-          <codeblock>$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'</codeblock>
+          <codeblock>$ psql dbname -c 'SELECT pid, state FROM pg_stat_replication;'</codeblock>
           <p>For information about the <codeph>pg_stat_replication</codeph> system view, see the
               <i>Greenplum Database Reference Guide</i>. </p>
         </section>
@@ -554,7 +554,7 @@ mirror3=3:sdw2:sdw2-2:52002:53002:54002:/gpdata/mir1/gp3
             pg_stat_replication. The view lists information about the <codeph>walsender</codeph>
             process that is used for Greenplum Database master mirroring. For example, this command
             displays the process ID and state of the <codeph>walsender</codeph> process:</p>
-          <codeblock>$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'</codeblock>
+          <codeblock>$ psql dbname -c 'SELECT pid, state FROM pg_stat_replication;'</codeblock>
         </section>
       </body>
     </topic>

gpdb-doc/dita/admin_guide/managing/startstop.xml

@@ -164,14 +164,14 @@
       </ul></p>
       <p>If you provide a <codeph>msg</codeph>, Greenplum Database includes the text in the cancel message returned to the client. <codeph>msg</codeph> is limited to 128 bytes; Greenplum Database truncates anything longer.</p>
       <p>The <codeph>pg_cancel_backend()</codeph> and <codeph>pg_terminate_backend()</codeph> functions return <codeph>true</codeph> if successful, and <codeph>false</codeph> otherwise.</p>
-      <p>To cancel or terminate a backend process, you must first identify the process ID of the backend. You can obtain the process ID from the <codeph>procpid</codeph> column of the <codeph>pg_stat_activity</codeph> view. For example, to view the process information associated with all running and queued queries: <codeblock>=# SELECT usename, procpid, waiting, current_query, datname
+      <p>To cancel or terminate a backend process, you must first identify the process ID of the backend. You can obtain the process ID from the <codeph>pid</codeph> column of the <codeph>pg_stat_activity</codeph> view. For example, to view the process information associated with all running and queued queries: <codeblock>=# SELECT usename, pid, waiting, current_query, datname
      FROM pg_stat_activity;</codeblock></p>
       <p>Sample partial query output:</p>
-        <codeblock> usename |  procpid | waiting |     current_query     | datname
+        <codeblock> usename |  pid     | waiting |     current_query     | datname
 ---------+----------+---------+-----------------------+---------
   sammy  |   31861  |    f    | &lt;IDLE&gt; in transaction | testdb
   billy  |   31905  |    t    | SELECT * FROM topten; | testdb</codeblock>
-      <p>Use the output to identify the process id (<codeph>procpid</codeph>) of the query
+      <p>Use the output to identify the process id (<codeph>pid</codeph>) of the query
         or client connection. </p>
       <p>For example, to cancel the pending query identified in the sample output above
         and include "Admin canceled long-running query." in the message returned to the client:</p>

gpdb-doc/dita/admin_guide/monitoring/monitoring.dita

@@ -160,7 +160,7 @@ FROM gp_master_mirroring;</codeblock></p>
                                         minutes</p><p>Severity: IMPORTANT</p></entry>
                                 <entry>
                                     <p>Run the following <codeph>psql</codeph>
-                                        command:<codeblock>psql <i>dbname</i> -c 'SELECT procpid, state FROM pg_stat_replication;'</codeblock></p>
+                                        command:<codeblock>psql <i>dbname</i> -c 'SELECT pid, state FROM pg_stat_replication;'</codeblock></p>
                                 </entry>
                                 <entry>
                                     <p>Check the <filepath>pg_log</filepath> file from the master

gpdb-doc/dita/admin_guide/perf_troubleshoot.xml

@@ -68,14 +68,14 @@
                     join its relation column against <codeph>pg_class.oid</codeph> to identify
                     locked relations (such as tables), but this works correctly only for relations
                     in the current database. You can join the <codeph>pid</codeph> column to the
-                        <codeph>pg_stat_activity.procpid</codeph> to see more information about the
+                        <codeph>pg_stat_activity.pid</codeph> to see more information about the
                     session holding or waiting to hold a lock. For example:</p>
                 <p>
                     <codeblock>SELECT locktype, database, c.relname, l.relation, 
 l.transactionid, l.pid, l.mode, l.granted, 
 a.current_query 
         FROM pg_locks l, pg_class c, pg_stat_activity a 
-        WHERE l.relation=c.oid AND l.pid=a.procpid 
+        WHERE l.relation=c.oid AND l.pid=a.pid
         ORDER BY c.relname;
 </codeblock>
                 </p>

gpdb-doc/dita/admin_guide/workload_mgmt.xml

@@ -737,7 +737,7 @@ MEMORY_LIMIT='2000MB');
         pg_stat_activity 
    WHERE pg_roles.rolresqueue=pg_locks.objid 
    AND pg_locks.objid=gp_toolkit.gp_resqueue_status.queueid
-   AND pg_stat_activity.procpid=pg_locks.pid
+   AND pg_stat_activity.pid=pg_locks.pid
    AND pg_stat_activity.usename=pg_roles.rolname;
 </codeblock>
         </p>

gpdb-doc/dita/admin_guide/workload_mgmt_resgroups.xml

@@ -955,18 +955,18 @@ gpstart
           active or waiting in all resource groups, run the following query. If the query returns no
           results, then there are no running or queued transactions in any resource group.</p>
         <p>
-          <codeblock>=# SELECT rolname, g.rsgname, procpid, waiting, current_query, datname 
+          <codeblock>=# SELECT rolname, g.rsgname, pid, waiting, current_query, datname 
      FROM pg_roles, gp_toolkit.gp_resgroup_status g, pg_stat_activity 
      WHERE pg_roles.rolresgroup=g.groupid
         AND pg_stat_activity.usename=pg_roles.rolname;
 </codeblock>
         </p>
         <p>Sample partial query output:</p>
-        <codeblock> rolname | rsgname  | procpid | waiting |     current_query     | datname 
+        <codeblock> rolname | rsgname  | pid     | waiting |     current_query     | datname 
 ---------+----------+---------+---------+-----------------------+---------
   sammy  | rg_light |  31861  |    f    | &lt;IDLE&gt; in transaction | testdb
   billy  | rg_light |  31905  |    t    | SELECT * FROM topten; | testdb</codeblock>
-        <p>Use this output to identify the process id (<codeph>procpid</codeph>) of the transaction
+        <p>Use this output to identify the process id (<codeph>pid</codeph>) of the transaction
           you want to cancel, and then cancel the process. For example, to cancel the pending query
           identified in the sample output above:</p>
         <p>

gpdb-doc/dita/ref_guide/sql_commands/DROP_RESOURCE_GROUP.xml

@@ -8,7 +8,7 @@ can drop a resource group. When you drop a resource group, the memory and CPU re
 nor can it have any statements pending or running in the group. If you drop a resource group that you created for an external component, the behavior is determined by the external component. For example, dropping a resource group that you assigned to a PL/Container runtime kills running containers in the group. </p><p>You cannot drop the pre-defined <codeph>admin_group</codeph> and <codeph>default_group</codeph> resource groups.</p>
 </section><section id="section4"><title>Parameters</title><parml><plentry><pt><varname>group_name</varname></pt><pd>The name of the resource group to remove.</pd></plentry></parml></section><section id="section5"><title>Notes</title><p>You cannot submit a <codeph>DROP RESOURCE GROUP</codeph> command in an explicit transaction or sub-transaction.</p><p>Use <codeph><xref href="ALTER_ROLE.xml#topic1" type="topic" format="dita"/></codeph> to remove a resource group assigned
         to a specific user/role.</p><p> Perform the following query to view all of the currently active
-        queries for all resource groups:</p><codeblock>SELECT usename, current_query, waiting, procpid,
+        queries for all resource groups:</p><codeblock>SELECT usename, current_query, waiting, pid,
     rsgid, rsgname, rsgqueueduration 
   FROM pg_stat_activity;
 </codeblock><p>To view the resource group assignments, perform the following query

gpdb-doc/dita/ref_guide/system_catalogs/pg_stat_replication.xml

@@ -2,6 +2,6 @@
 <!DOCTYPE topic
   PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
 <topic id="topic1" xml:lang="en"><title id="op164582">pg_stat_replication</title><body><p>The <codeph>pg_stat_replication</codeph> view contains metadata of the <codeph>walsender</codeph>
-      process that is used for Greenplum Database master mirroring.</p><table id="op164584"><title>pg_catalog.pg_stat_replication</title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="131pt"/><colspec colnum="2" colname="col2" colwidth="100pt"/><colspec colnum="3" colname="col3" colwidth="82pt"/><colspec colnum="4" colname="col4" colwidth="136pt"/><thead><row><entry colname="col1">column</entry><entry colname="col2">type</entry><entry colname="col3">references</entry><entry colname="col4">description</entry></row></thead><tbody><row><entry colname="col1"><codeph>procpid</codeph></entry><entry colname="col2">integer</entry><entry colname="col3"/><entry colname="col4">Process ID of WAL sender backend process. </entry></row><row><entry colname="col1"><codeph>usesysid</codeph></entry><entry colname="col2">integer</entry><entry colname="col3"/><entry colname="col4">User system ID that runs the WAL sender backend
+      process that is used for Greenplum Database master mirroring.</p><table id="op164584"><title>pg_catalog.pg_stat_replication</title><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="131pt"/><colspec colnum="2" colname="col2" colwidth="100pt"/><colspec colnum="3" colname="col3" colwidth="82pt"/><colspec colnum="4" colname="col4" colwidth="136pt"/><thead><row><entry colname="col1">column</entry><entry colname="col2">type</entry><entry colname="col3">references</entry><entry colname="col4">description</entry></row></thead><tbody><row><entry colname="col1"><codeph>pid</codeph></entry><entry colname="col2">integer</entry><entry colname="col3"/><entry colname="col4">Process ID of WAL sender backend process. </entry></row><row><entry colname="col1"><codeph>usesysid</codeph></entry><entry colname="col2">integer</entry><entry colname="col3"/><entry colname="col4">User system ID that runs the WAL sender backend
 process</entry></row><row><entry colname="col1"><codeph>usename</codeph></entry><entry colname="col2">name</entry><entry colname="col3"/><entry colname="col4">User name that runs WAL sender backend process.</entry></row><row><entry colname="col1"><codeph>application_name</codeph></entry><entry colname="col2">oid</entry><entry colname="col3"/><entry colname="col4">Client application name.</entry></row><row><entry colname="col1"><codeph>client_addr </codeph></entry><entry colname="col2">name</entry><entry colname="col3"/><entry colname="col4">Client IP address.</entry></row><row><entry colname="col1"><codeph>client_port </codeph></entry><entry colname="col2">integer</entry><entry colname="col3"/><entry colname="col4">Client port number.</entry></row><row><entry colname="col1"><codeph>backend_start </codeph></entry><entry colname="col2">timestamp </entry><entry colname="col3"/><entry colname="col4">Operation start timestamp. </entry></row><row><entry colname="col1"><codeph>state</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">WAL sender state. The value can
                   be:<p><codeph>startup</codeph></p><p><codeph>backup</codeph></p><p><codeph>catchup</codeph></p><p><codeph>streaming</codeph></p></entry></row><row><entry colname="col1"><codeph>sent_location</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">WAL sender xlog record sent location.</entry></row><row><entry colname="col1"><codeph>write_location</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">WAL receiver xlog record write location.</entry></row><row><entry colname="col1"><codeph>flush_location</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">WAL receiver xlog record flush location.</entry></row><row><entry colname="col1"><codeph>replay_location</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">Standby xlog record replay location.</entry></row><row><entry colname="col1"><codeph>sync_priority</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">Priority. the value is <codeph>1</codeph>.</entry></row><row><entry colname="col1"><codeph>sync_state</codeph></entry><entry colname="col2">text</entry><entry colname="col3"/><entry colname="col4">WAL sender synchronization state. The value is <codeph>sync</codeph>.</entry></row></tbody></tgroup></table></body></topic>

src/test/regress/expected/wrkloadadmin_resgroup.out

@@ -680,7 +680,7 @@ SELECT rolname, rsqname, pid, granted, current_query,datname FROM pg_roles, pg_r
 
 
 -- create a view
-CREATE VIEW resq_procs AS SELECT rolname, rsqname, pid, granted, current_query,datname FROM pg_roles, pg_resqueue, pg_locks, pg_stat_activity WHERE pg_roles.rolresqueue=pg_locks.objid AND pg_locks.objid=pg_resqueue.oid AND pg_stat_activity.procpid=pg_locks.pid;
+CREATE VIEW resq_procs AS SELECT rolname, rsqname, pid, granted, current_query,datname FROM pg_roles, pg_resqueue, pg_locks, pg_stat_activity WHERE pg_roles.rolresqueue=pg_locks.objid AND pg_locks.objid=pg_resqueue.oid AND pg_stat_activity.pid=pg_locks.pid;
 
 -- select from view
 select * from resq_procs;