Replace BackendIds with 0-based ProcNumbers

Now that BackendId was just another index into the proc array, it was
redundant with the 0-based proc numbers used in other places. Replace
all usage of backend IDs with proc numbers.

The only place where the term "backend id" remains is in a few pgstat
functions that expose backend IDs at the SQL level. Those IDs are now
in fact 0-based ProcNumbers too, but the documentation still calls
them "backend ids". That term still seems appropriate to describe what
the numbers are, so I let it be.

One user-visible effect is that pg_temp_0 is now a valid temp schema
name, for backend with ProcNumber 0.

Reviewed-by: Andres Freund
Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi

Author: hlinnaka

doc/src/sgml/config.sgml

@@ -7495,7 +7495,7 @@ local0.*    /var/log/postgresql
             </row>
             <row>
              <entry><literal>%v</literal></entry>
-             <entry>Virtual transaction ID (backendID/localXID);  see
+             <entry>Virtual transaction ID (procNumber/localXID);  see
              <xref linkend="transaction-id"/></entry>
              <entry>no</entry>
             </row>

doc/src/sgml/monitoring.sgml

@@ -4940,7 +4940,7 @@ description | Waiting for a newly initialized WAL file to reach durable storage
    access functions can be used; these are shown in <xref
    linkend="monitoring-stats-backend-funcs-table"/>.
    These access functions use the session's backend ID number, which is a
-   small positive integer that is distinct from the backend ID of any
+   small integer (>= 0) that is distinct from the backend ID of any
    concurrent session, although a session's ID can be recycled as soon as
    it exits.  The backend ID is used, among other things, to identify the
    session's temporary schema if it has one.
@@ -6813,7 +6813,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
        arg0 contains the fork to be extended. arg1, arg2, and arg3 contain the
        tablespace, database, and relation OIDs identifying the relation.  arg4
        is the ID of the backend which created the temporary relation for a
-       local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared
+       local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared
        buffer. arg5 is the number of blocks the caller would like to extend
        by.</entry>
     </row>
@@ -6824,7 +6824,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
        arg0 contains the fork to be extended. arg1, arg2, and arg3 contain the
        tablespace, database, and relation OIDs identifying the relation.  arg4
        is the ID of the backend which created the temporary relation for a
-       local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared
+       local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared
        buffer. arg5 is the number of blocks the relation was extended by, this
        can be less than the number in the
        <literal>buffer-extend-start</literal> due to resource
@@ -6839,7 +6839,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
       </entry>
     </row>
     <row>
@@ -6850,7 +6850,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
       arg6 is true if the buffer was found in the pool, false if not.</entry>
     </row>
     <row>
@@ -6903,7 +6903,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.</entry>
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.</entry>
     </row>
     <row>
      <entry><literal>smgr-md-read-done</literal></entry>
@@ -6913,7 +6913,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
       arg6 is the number of bytes actually read, while arg7 is the number
       requested (if these are different it indicates a short read).</entry>
     </row>
@@ -6925,7 +6925,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.</entry>
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.</entry>
     </row>
     <row>
      <entry><literal>smgr-md-write-done</literal></entry>
@@ -6935,7 +6935,7 @@ FROM pg_stat_get_backend_idset() AS backendid;
       arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
       identifying the relation.
       arg5 is the ID of the backend which created the temporary relation for a
-      local buffer, or <symbol>InvalidBackendId</symbol> (-1) for a shared buffer.
+      local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
       arg6 is the number of bytes actually written, while arg7 is the number
       requested (if these are different it indicates a short write).</entry>
     </row>

doc/src/sgml/storage.sgml

@@ -202,7 +202,7 @@ these files are named after the table or index's <firstterm>filenode</firstterm>
 which can be found in <structname>pg_class</structname>.<structfield>relfilenode</structfield>. But
 for temporary relations, the file name is of the form
 <literal>t<replaceable>BBB</replaceable>_<replaceable>FFF</replaceable></literal>, where <replaceable>BBB</replaceable>
-is the backend ID of the backend which created the file, and <replaceable>FFF</replaceable>
+is the process number of the backend which created the file, and <replaceable>FFF</replaceable>
 is the filenode number.  In either case, in addition to the main file (a/k/a
 main fork), each table and index has a <firstterm>free space map</firstterm> (see <xref
 linkend="storage-fsm"/>), which stores information about free space available in

doc/src/sgml/xact.sgml

@@ -26,10 +26,10 @@
    Every transaction is identified by a unique
    <literal>VirtualTransactionId</literal> (also called
    <literal>virtualXID</literal> or <literal>vxid</literal>), which
-   is comprised of a backend ID (or <literal>backendID</literal>)
+   is comprised of a backend's process number (or <literal>procNumber</literal>)
    and a sequentially-assigned number local to each backend, known as
    <literal>localXID</literal>.  For example, the virtual transaction
-   ID <literal>4/12532</literal> has a <literal>backendID</literal>
+   ID <literal>4/12532</literal> has a <literal>procNumber</literal>
    of <literal>4</literal> and a <literal>localXID</literal> of
    <literal>12532</literal>.
   </para>

src/backend/access/transam/README

@@ -203,12 +203,12 @@ pg_subtrans and PGPROC are done at the time it is assigned.
 A transaction that has no XID still needs to be identified for various
 purposes, notably holding locks.  For this purpose we assign a "virtual
 transaction ID" or VXID to each top-level transaction.  VXIDs are formed from
-two fields, the backendID and a backend-local counter; this arrangement allows
-assignment of a new VXID at transaction start without any contention for
-shared memory.  To ensure that a VXID isn't re-used too soon after backend
+two fields, the procNumber and a backend-local counter; this arrangement
+allows assignment of a new VXID at transaction start without any contention
+for shared memory.  To ensure that a VXID isn't re-used too soon after backend
 exit, we store the last local counter value into shared memory at backend
-exit, and initialize it from the previous value for the same backendID slot
-at backend start.  All these counters go back to zero at shared memory
+exit, and initialize it from the previous value for the same PGPROC slot at
+backend start.  All these counters go back to zero at shared memory
 re-initialization, but that's OK because VXIDs never appear anywhere on-disk.
 
 Internally, a backend needs a way to identify subtransactions whether or not

src/backend/access/transam/clog.c

@@ -501,15 +501,15 @@ TransactionGroupUpdateXidStatus(TransactionId xid, XidStatus status,
 		 * still work, just less efficiently -- we handle this case by
 		 * switching to a different bank lock in the loop below.
 		 */
-		if (nextidx != INVALID_PGPROCNO &&
+		if (nextidx != INVALID_PROC_NUMBER &&
 			GetPGProcByNumber(nextidx)->clogGroupMemberPage != proc->clogGroupMemberPage)
 		{
 			/*
 			 * Ensure that this proc is not a member of any clog group that
 			 * needs an XID status update.
 			 */
 			proc->clogGroupMember = false;
-			pg_atomic_write_u32(&proc->clogGroupNext, INVALID_PGPROCNO);
+			pg_atomic_write_u32(&proc->clogGroupNext, INVALID_PROC_NUMBER);
 			return false;
 		}
 
@@ -525,9 +525,9 @@ TransactionGroupUpdateXidStatus(TransactionId xid, XidStatus status,
 	 * If the list was not empty, the leader will update the status of our
 	 * XID. It is impossible to have followers without a leader because the
 	 * first process that has added itself to the list will always have
-	 * nextidx as INVALID_PGPROCNO.
+	 * nextidx as INVALID_PROC_NUMBER.
 	 */
-	if (nextidx != INVALID_PGPROCNO)
+	if (nextidx != INVALID_PROC_NUMBER)
 	{
 		int			extraWaits = 0;
 
@@ -543,7 +543,7 @@ TransactionGroupUpdateXidStatus(TransactionId xid, XidStatus status,
 		}
 		pgstat_report_wait_end();
 
-		Assert(pg_atomic_read_u32(&proc->clogGroupNext) == INVALID_PGPROCNO);
+		Assert(pg_atomic_read_u32(&proc->clogGroupNext) == INVALID_PROC_NUMBER);
 
 		/* Fix semaphore count for any absorbed wakeups */
 		while (extraWaits-- > 0)
@@ -568,13 +568,13 @@ TransactionGroupUpdateXidStatus(TransactionId xid, XidStatus status,
 	 * group.
 	 */
 	nextidx = pg_atomic_exchange_u32(&procglobal->clogGroupFirst,
-									 INVALID_PGPROCNO);
+									 INVALID_PROC_NUMBER);
 
 	/* Remember head of list so we can perform wakeups after dropping lock. */
 	wakeidx = nextidx;
 
 	/* Walk the list and update the status of all XIDs. */
-	while (nextidx != INVALID_PGPROCNO)
+	while (nextidx != INVALID_PROC_NUMBER)
 	{
 		PGPROC	   *nextproc = &ProcGlobal->allProcs[nextidx];
 		int			thispageno = nextproc->clogGroupMemberPage;
@@ -633,12 +633,12 @@ TransactionGroupUpdateXidStatus(TransactionId xid, XidStatus status,
 	 * clogGroupNext to invalid while saving the semaphores to an array, then
 	 * a single write barrier, then another pass unlocking the semaphores.)
 	 */
-	while (wakeidx != INVALID_PGPROCNO)
+	while (wakeidx != INVALID_PROC_NUMBER)
 	{
 		PGPROC	   *wakeproc = &ProcGlobal->allProcs[wakeidx];
 
 		wakeidx = pg_atomic_read_u32(&wakeproc->clogGroupNext);
-		pg_atomic_write_u32(&wakeproc->clogGroupNext, INVALID_PGPROCNO);
+		pg_atomic_write_u32(&wakeproc->clogGroupNext, INVALID_PROC_NUMBER);
 
 		/* ensure all previous writes are visible before follower continues. */
 		pg_write_barrier();