From: Amit Kapila <amit.kapila16@gmail.com>
> The idea is that we can't use this optimization if the value is not
> cached because we can't rely on lseek behavior. See all the discussion
> between Horiguchi-San and me in the thread above. So, how would you
> ensure that if we don't use Kirk-San's proposal?
Hmm, buggy Linux kernel... (Until when should we be worried about the bug?)
According to the following Horiguchi-san's suggestion, it's during normal operation, not during recovery, when we
shouldbe careful, right? Then, we can use the current smgrnblocks() as is?
+ /*
+ * We cannot believe the result from smgr_nblocks is always accurate
+ * because lseek of buggy Linux kernels doesn't account for a recent
+ * write. However, we can rely on the result from lseek while recovering
+ * because the first call to this function is not happen just after a file
+ * extension. Return values on subsequent calls return cached nblocks,
+ * which should be accurate during recovery.
+ */
+ if (!InRecovery && must_accurate)
+ return InvalidBlockNumber;
+
return result;
}
If smgrnblocks() could return a smaller value than the actual file size by one block even during recovery, how about
alwaysadding one to the return value of smgrnblocks() in DropRelFileNodeBuffers()? When smgrnblocks() actually
returnedthe correct value, the extra one block is not found in the shared buffer, so DropRelFileNodeBuffers() does no
harm.
Or, add a new function like smgrnblocks_precise() to avoid adding an argument to smgrnblocks()?
Regards
Takayuki Tsunakawa