On Mon, Oct 24, 2016 at 1:39 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Oct 24, 2016 at 9:18 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> Thank you for looking and retelling this.
+1. >> At Fri, 21 Oct 2016 13:02:21 -0400, Robert Haas <robertmh...@gmail.com> >> wrote in <ca+tgmoardyfcqcg9x-e99xcxdc4lw0zygp5qlsphfsb6byd...@mail.gmail.com> >>> I can think of two solutions that would be "tighter": >>> >>> 1. When performing a restartpoint, update the minimum recovery point >>> to just beyond the checkpoint record. I think this can't hurt anyone >>> who is actually restarting recovery on the same machine, because >>> that's exactly the point where they are going to start recovery. A >>> minimum recovery point which precedes the point at which they will >>> start recovery is no better than one which is equal to the point at >>> which they will start recovery. >> >> This is a candidate that I thought of. But I avoided to change >> the behavior of minRecoveryPoint that (seems to me that) it >> describes only buffer state. So checkpoint with no update doesn't >> advances minRecoveryPoint as my understanding. > > I think what you are saying is not completely right, because we do > update minRecoveryPoint when we don't perform a new restart point. > When we perform restart point, then it assumes that flushing the > buffers will take care of updating minRecoveryPoint. Yep, minRecoveryPoint still gets updated when the last checkpoint record is the last restart point to avoid a hot standby to allow read-only connections at a LSN-point earlier than the last shutdown. 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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
