On Tue, Oct 25, 2016 at 11:07 AM, Kyotaro HORIGUCHI <[email protected]> wrote: > At Mon, 24 Oct 2016 15:55:58 +0900, Michael Paquier > <[email protected]> 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. -- Michael -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
