RE: [Patch] Optimize dropping of relation buffers using dlist

From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> So I proceeded to update the patches using the "cached" parameter and
> updated the corresponding comments to it in 0002.

OK, I'm in favor of the name "cached" now, although I first agreed with Horiguchi-san in that it's better to use a name
thatrepresents the nature (accurate) of information rather than the implementation (cached).  Having a second thought,
sincesmgr is a component that manages relation files on storage (file system), lseek(SEEK_END) is the accurate value
forsmgr.  The cached value holds a possibly stale size up to which the relation has extended. 


The patch looks almost good except for the minor ones:

(1)
+extern BlockNumber smgrnblocks(SMgrRelation reln, ForkNumber forknum,
+                               bool *accurate);

It's still accurate here.


(2)
+ *        the buffer pool is sequentially scanned. Since buffers must not be
+ *        left behind, the latter way is executed unless the sizes of all the
+ *        involved forks are already cached. See smgrnblocks() for more details.
+ *        This is only called in recovery when the block count of any fork is
+ *        cached and the total number of to-be-invalidated blocks per relation

count of any fork is
-> counts of all forks are


(3)
In 0004, I thought you would add the invalidated block counts of all relations to determine if the optimization is
done,as Horiguchi-san suggested.  But I find the current patch okay too. 


Regards
Takayuki Tsunakawa