On Tue, Oct 25, 2016 at 11:07 AM, Kyotaro HORIGUCHI
<horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Mon, 24 Oct 2016 15:55:58 +0900, Michael Paquier 
> <michael.paqu...@gmail.com> wrote in 
> <cab7npqtdne62f9rvxwvow4ihcy9ivmgeyjeozjdqyv5pf7y...@mail.gmail.com>
>> Anyway, we can clearly reject 1. in the light of
>> https://www.postgresql.org/message-id/caa4ek1kmjtsxqf0cav7cs4d4vwv2h_pc8d8q1bucqdzaf+7...@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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to