At Mon, 7 Dec 2020 17:18:31 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in > On Mon, Dec 7, 2020 at 12:32 PM k.jami...@fujitsu.com > <k.jami...@fujitsu.com> wrote: > > > > On Friday, December 4, 2020 8:27 PM, Amit Kapila <amit.kapil...@gmail.com> > > wrote: > > Hi, > > I have reported before that it is not always the case that the "cached" > > flag of > > srnblocks() return true. So when I checked the truncate test case used in my > > patch, it does not enter the optimization path despite doing INSERT before > > truncation of table. > > The reason for that is because in TRUNCATE, a new RelFileNode is assigned > > to the relation when creating a new file. In recovery, > > XLogReadBufferExtended() > > always opens the RelFileNode and calls smgrnblocks() for that RelFileNode > > for the > > first time. And for recovery processing, different RelFileNodes are used > > for the > > INSERTs to the table and TRUNCATE to the same table. > > > > Hmm, how is it possible if Insert is done before Truncate? The insert > should happen in old RelFileNode only. I have verified by adding a > break-in (while (1), so that it stops there) heap_xlog_insert and > DropRelFileNodesAllBuffers(), and both get the same (old) RelFileNode. > How have you verified what you are saying?
You might be thinking of in-transaction sequence of Inert-truncate. What *I* mention before is truncation of a relation that smgrnblocks() has already been called for. The most common way to make it happen was INSERTs *before* the truncating transaction starts. It may be a SELECT on a hot-standby. Sorry for the confusing expression. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
