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
