At Thu, 22 Oct 2020 14:16:37 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> At Thu, 22 Oct 2020 16:35:27 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in
> > On Thu, Oct 22, 2020 at 3:07 PM k.jamison@fujitsu.com
> > <k.jamison@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