Re: [BUG] pg_basebackup from disconnected standby fails

On Sun, Oct 23, 2016 at 11:48 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> 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 don't really know what you mean by this. minRecoveryPoint is the
point up to which we need to replay WAL in order to achieve
consistency - the distinction between "buffer state" and something
else is artificial. My point is that the amount of WAL we need to
replay can never be negative, but that's what a minimum recovery point
prior to the end of the checkpoint record used for start-of-REDO
implies.

>> 2. In perform_base_backup(), if the endptr returned by
>> do_pg_stop_backup() precedes the end of the checkpoint record returned
>> by do_pg_start_backup(), use the latter value instead. Unfortunately,
>> that's not so easy: we can't just say if (endptr < starptr) startptr =
>> endptr; because startptr is the *start* of the checkpoint record, not
>> the end. I suspect somebody could figure out a solution to this
>> problem, though.
>
> Yes, and the reason I rejected it was that it is not logical,
> maybe the same meaning to it would cause another problem later.

I don't know why this isn't logical. If you want to say it's going to
cause another problem later, you should say what problem you think it
will cause, not just guess that there might be one.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company