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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
