On Tue, Dec 8, 2020 at 7:24 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> I'm out of it more than usual..
>
> At Tue, 08 Dec 2020 09:45:53 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> > At Mon, 7 Dec 2020 17:18:31 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
> > > On Mon, Dec 7, 2020 at 12:32 PM k.jamison@fujitsu.com
> > > <k.jamison@fujitsu.com> wrote:
> > > >
> > > > On Friday, December 4, 2020 8:27 PM, Amit Kapila <amit.kapila16@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?
>
> It's irrelvant that the insert happens on the old relfilenode.
>
I think it is relevant because it will allow the 'blocks' value to be cached.
> 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?
--
With Regards,
Amit Kapila.
