On Wed, Sep 2, 2020 at 7:01 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > Hello. > > At Tue, 1 Sep 2020 13:02:28 +0000, "k.jami...@fujitsu.com" > <k.jami...@fujitsu.com> wrote in > > On Tuesday, August 18, 2020 3:05 PM (GMT+9), Amit Kapila wrote: > > > Today, again thinking about this point it occurred to me that during > > > recovery > > > we can reliably find the relation size and after Thomas's recent commit > > > c5315f4f44 (Cache smgrnblocks() results in recovery), we might not need to > > > even incur the cost of lseek. Why don't we fix this first for 'recovery' > > > (by > > > following something on the lines of what Andres suggested) and then later > > > once we have a generic mechanism for "caching the relation size" [1], we > > > can > > > do it for non-recovery paths. > > > I think that will at least address the reported use case with some minimal > > > changes. > > > > > > [1] - > > > https://www.postgresql.org/message-id/CAEepm%3D3SSw-Ty1DFcK%3D1r > > > U-K6GSzYzfdD4d%2BZwapdN7dTa6%3DnQ%40mail.gmail.com > > Isn't a relation always locked asscess-exclusively, at truncation > time? If so, isn't even the result of lseek reliable enough? >
Even if the relation is locked, background processes like checkpointer can still touch the relation which might cause problems. Consider a case where we extend the relation but didn't flush the newly added pages. Now during truncate operation, checkpointer can still flush those pages which can cause trouble for truncate. But, I think in the recovery path such cases won't cause a problem. -- With Regards, Amit Kapila.
