On Tue, Oct 25, 2016 at 11:07 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> At Mon, 24 Oct 2016 15:55:58 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqTDnE62F9RVXwvOw4ihCy9iVMgEYJeozjDQYV5pF7YvFg@mail.gmail.com>
>> Anyway, we can clearly reject 1. in the light of
>> https://www.postgresql.org/message-id/CAA4eK1KmjtsXqF0cav7Cs4d4vwv2H_pc8d8q1BUCqDzAF+7EzQ@mail.gmail.com
>> when playing with different stop locations at recovery.
>
> | * If the last checkpoint record we've replayed is already our last
> | * restartpoint, we can't perform a new restart point. We still update
> | * minRecoveryPoint in that case, so that if this is a shutdown restart
> | * point, we won't start up earlier than before.
> ...
> | * We don't explicitly advance minRecoveryPoint when we do create a
> | * restartpoint. It's assumed that flushing the buffers will do that as a
> | * side-effect.
>
> The second sentence seems to me as "we *expect* minRecoveryPoint
> to be updated anyway even if we don't do that here". Though a bit
> different in reality..it.
>
> skipped checkpoints - advance minRecvoeryPoint to the checkpoint
>
> I'm failing to make a consistent model for the code around here
> in my mind..
Hm? If the last checkpoint record replayed is the last restart point,
no restart point is created *but* minRecoveryPoint is updated to
prevent the case where read only queries are allowed earlier than the
next startup point. On the other hand, if a restart point is created,
this code does not update minRecoveryPoint and it is assumed that the
next buffer flush will do it.
--
Michael
