At Tue, 8 Dec 2020 08:08:25 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in > On Tue, Dec 8, 2020 at 7:24 AM Kyotaro Horiguchi > <horikyota....@gmail.com> wrote: > > We drop > > buffers for the old relfilenode on truncation anyway. > > > > What I did is: > > > > a: Create a physical replication pair. > > b: On the master, create a table. (without explicitly starting a tx) > > c: On the master, insert a tuple into the table. > > d: On the master truncate the table. > > > > On the standby, smgrnblocks is called for the old relfilenode of the > > table at c, then the same function is called for the same relfilenode > > at d and the function takes the cached path. > > > > This is on the lines I have tried for recovery. So, it seems we are in > agreement that we can use the 'cached' flag in > DropRelFileNodesAllBuffers and it will take the optimized path in many > such cases, right?
Mmm. There seems to be a misunderstanding.. What I opposed to is referring only to InRecovery and ignoring the value of "cached". The remaining issue is we don't get to the optimized path when a standby makes the first call to smgrnblocks() when truncating a relation. Still we can get to the optimized path as far as any update(+insert) or select is performed earlier on the relation so I think it doesn't matter so match. But I'm not sure what others think. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
