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.


>> 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
when playing with different stop locations at recovery.

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

Reply via email to