Change internal RelFileNode references to RelFileNumber or RelFileLocator.

We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.

Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".

Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.

On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.

Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.

Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.

Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com

1 files changed, 15 insertions, 14 deletions

diff --git a/src/backend/access/common/syncscan.c b/src/backend/access/common/syncscan.c
index d5b16c5bff0..ad48cb741fe 100644
--- a/src/backend/access/common/syncscan.c
+++ b/src/backend/access/common/syncscan.c
@@ -90,7 +90,7 @@ bool		trace_syncscan = false;
  */
 typedef struct ss_scan_location_t
 {
-	RelFileNode relfilenode;	/* identity of a relation */
+	RelFileLocator relfilelocator;	/* identity of a relation */
 	BlockNumber location;		/* last-reported location in the relation */
 } ss_scan_location_t;
 
@@ -115,7 +115,7 @@ typedef struct ss_scan_locations_t
 static ss_scan_locations_t *scan_locations;
 
 /* prototypes for internal functions */
-static BlockNumber ss_search(RelFileNode relfilenode,
+static BlockNumber ss_search(RelFileLocator relfilelocator,
 							 BlockNumber location, bool set);
 
 
@@ -159,9 +159,9 @@ SyncScanShmemInit(void)
 			 * these invalid entries will fall off the LRU list and get
 			 * replaced with real entries.
 			 */
-			item->location.relfilenode.spcNode = InvalidOid;
-			item->location.relfilenode.dbNode = InvalidOid;
-			item->location.relfilenode.relNode = InvalidOid;
+			item->location.relfilelocator.spcOid = InvalidOid;
+			item->location.relfilelocator.dbOid = InvalidOid;
+			item->location.relfilelocator.relNumber = InvalidRelFileNumber;
 			item->location.location = InvalidBlockNumber;
 
 			item->prev = (i > 0) ?
@@ -176,10 +176,10 @@ SyncScanShmemInit(void)
 
 /*
  * ss_search --- search the scan_locations structure for an entry with the
- *		given relfilenode.
+ *		given relfilelocator.
  *
  * If "set" is true, the location is updated to the given location.  If no
- * entry for the given relfilenode is found, it will be created at the head
+ * entry for the given relfilelocator is found, it will be created at the head
  * of the list with the given location, even if "set" is false.
  *
  * In any case, the location after possible update is returned.
@@ -188,7 +188,7 @@ SyncScanShmemInit(void)
  * data structure.
  */
 static BlockNumber
-ss_search(RelFileNode relfilenode, BlockNumber location, bool set)
+ss_search(RelFileLocator relfilelocator, BlockNumber location, bool set)
 {
 	ss_lru_item_t *item;
 
@@ -197,7 +197,8 @@ ss_search(RelFileNode relfilenode, BlockNumber location, bool set)
 	{
 		bool		match;
 
-		match = RelFileNodeEquals(item->location.relfilenode, relfilenode);
+		match = RelFileLocatorEquals(item->location.relfilelocator,
+									 relfilelocator);
 
 		if (match || item->next == NULL)
 		{
@@ -207,7 +208,7 @@ ss_search(RelFileNode relfilenode, BlockNumber location, bool set)
 			 */
 			if (!match)
 			{
-				item->location.relfilenode = relfilenode;
+				item->location.relfilelocator = relfilelocator;
 				item->location.location = location;
 			}
 			else if (set)
@@ -255,7 +256,7 @@ ss_get_location(Relation rel, BlockNumber relnblocks)
 	BlockNumber startloc;
 
 	LWLockAcquire(SyncScanLock, LW_EXCLUSIVE);
-	startloc = ss_search(rel->rd_node, 0, false);
+	startloc = ss_search(rel->rd_locator, 0, false);
 	LWLockRelease(SyncScanLock);
 
 	/*
@@ -281,8 +282,8 @@ ss_get_location(Relation rel, BlockNumber relnblocks)
  * ss_report_location --- update the current scan location
  *
  * Writes an entry into the shared Sync Scan state of the form
- * (relfilenode, blocknumber), overwriting any existing entry for the
- * same relfilenode.
+ * (relfilelocator, blocknumber), overwriting any existing entry for the
+ * same relfilelocator.
  */
 void
 ss_report_location(Relation rel, BlockNumber location)
@@ -309,7 +310,7 @@ ss_report_location(Relation rel, BlockNumber location)
 	{
 		if (LWLockConditionalAcquire(SyncScanLock, LW_EXCLUSIVE))
 		{
-			(void) ss_search(rel->rd_node, location, true);
+			(void) ss_search(rel->rd_locator, location, true);
 			LWLockRelease(SyncScanLock);
 		}
 #ifdef TRACE_SYNCSCAN