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