RE: [Patch] Optimize dropping of relation buffers using dlist

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> We are relying on the "fact" that the first lseek() call of a
> (startup) process tells the truth.  We added an assertion so that we
> make sure that the cached value won't be cleared during recovery.  A
> possible remaining danger would be closing of an smgr object of a live
> relation just after a file extension failure. I think we are thinking
> that that doesn't happen during recovery.  Although it seems to me
> true, I'm not confident.
>
> If that's true, we don't even need to look at the "cached" flag at all
> and always be able to rely on the returned value from msgrnblocks()
> during recovery.  Otherwise, we need to avoid the danger situation.

Hmm, I've gotten to think that smgrnblocks() doesn't need the cached parameter, too.  DropRel*Buffers() can just check
InRecovery. Regarding the only concern about smgrclose() by startup process, I was afraid of the cache invalidation by
CacheInvalidateSmgr(),but startup process doesn't receive shared inval messages.  So, it doesn't call smgrclose*() due
toshared cache invalidation. 

[InitRecoveryTransactionEnvironment()]
    /* Initialize shared invalidation management for Startup process, being
     * Initialize shared invalidation management for Startup process, being
     * careful to register ourselves as a sendOnly process so we don't need to
     * read messages, nor will we get signaled when the queue starts filling
     * up.
     */
    SharedInvalBackendInit(true);


Kirk-san,
Can you check to see if smgrclose() and its friends are not called during recovery using the regression test?



Regards
Takayuki Tsunakawa