At Thu, 22 Oct 2020 14:16:37 +0900 (JST), Kyotaro Horiguchi <horikyota....@gmail.com> wrote in > At Thu, 22 Oct 2020 16:35:27 +1300, Thomas Munro <thomas.mu...@gmail.com> > wrote in > > On Thu, Oct 22, 2020 at 3:07 PM k.jami...@fujitsu.com > > <k.jami...@fujitsu.com> wrote: > > But... does the proposed caching behaviour and "accurate" flag really > > help with any of that? Cached values come from lseek() anyway. If we > > That "accurate" (good name wanted) flag suggest that it is guaranteed > that we don't have a buffer for blocks after that block number. > > > just trusted unmodified smgrnblocks(), someone running on such a > > forgetful file system might eventually see nasty errors because we > > left buffers in the buffer pool that prevent a checkpoint from > > completing (and panic?), but they might also see other really strange > > errors, and that applies with or without that "accurate" flag, no? > > > > [1] > > https://www.postgresql.org/message-id/flat/26202.1159032931%40sss.pgh.pa.us > > smgrtruncate and msgrextend modifies that cache from their parameter, > not from lseek(). At the very first the value in the cache comes from > lseek() but if nothing other than postgres have changed the file size, > I believe we can rely on the cache even with such a buggy kernels even > if still exists.
Mmm. Not exact. The requirement here is that we must be certain that the we don't have a buffuer for blocks after the file size known to the process. While recoverying, If the first lseek() returned smaller size than actual, we cannot have a buffer for the blocks after the size. After we trncated or extended the file, we are certain that we don't have a buffer for unknown blocks. > If there's no longer such a buggy kernel, we can rely on lseek() only > when InRecovery. If we had synchronized file size cache we could rely > on the cache even while !InRecovery. (I'm not sure about how vacuum > affects, though.) regards. -- Kyotaro Horiguchi NTT Open Source Software Center
