From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> On Thursday, December 10, 2020 8:12 PM, Amit Kapila wrote:
> > AFAIU, it won't take optimization path only when we have TOAST relation but
> > there is no insertion corresponding to it. If so, then we don't need to mention
> > it specifically because there are other similar cases where the optimization
> > won't work like when during recovery we have to just perform TRUNCATE.
> >
>
> Right, I forgot to add that there should be an update like insert to the TOAST
> relation for truncate optimization to work. However, that is only limited to
> TOAST relations with PLAIN strategy. I have tested with text data type, with
> Inserts before truncate, and it did not enter the optimization path. OTOH,
> It worked for data type like integer. So should I still not include that information?
What's valuable as a code comment to describe the remaining issue is that the reader can find clues to if this is
relatedto the problem he/she has hit, and/or how to solve the issue. I don't think the current comment is so bad in
thatregard, but it seems better to add:
* The condition of the issue: the table's ancillary storage (index, TOAST table, FSM, VM, etc.) was not updated during
recovery.
(As an aside, "during recovery" here does not mean "after the last checkpoint" but "from the start of recovery",
becausethe standby experiences many checkpoints (the correct term is restartpoints in case of standby).)
* The cause as a hint to solve the issue: The startup process does not find page modification WAL records. As a
result,it won't call XLogReadBufferExtended() and smgrnblocks() called therein, so the relation/fork size is not
cached.
Regards
Takayuki Tsunakawa