Hello,
At Tue, 14 Jun 2016 21:24:58 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQkJv-3Cbi=yDytoC9eWPfmjrj7-DLOn9C4YsB1twAKiw@mail.gmail.com>
> On Tue, Jun 14, 2016 at 8:31 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> >> +# Take a second backup of the standby while the master is offline.
> >> +$node_master->stop;
> >> +$node_standby_1->backup('my_backup_2');
> >> +$node_master->start;
> >
> > I'm not sure that adding the test case for a particular bug like
> > this is appropriate. But it would be acceptable because it
> > doesn't take long time and it is separate from standard checks.
>
> We already take a backup from a standby when master is connected, it
> should not cost much in terms of time.
Agreed.
> > It seems to me that we could more agressively advance the
> > minRecoveryPoint (but must not let it go too far..), but it is
> > right for it to aim a bit smaller than the ideal location.
>
> It may be risky to propose such a change for a backpatch. Anyway, in
> any case there is no guarantee that when using the low-level backup
> routines pg_start/stop_backup with a custom backup method the minimum
> recovery point will be correct.. pg_basebackup does that a bit more
> carefully if I recall correctly (too lazy to look at the code now :)).
Yes, as written in another mail, minRecoveryPoint seems to be
correctly upadtaed as its definition. The problem is that only
redo point of the last restartpoint is updated, even if no update
happened. But just inhibiting the update of redo point for the
case in turn causes an annoying repetition of restartpoints.
Addition to the TAP test above, the following SQL commands on the
master causes the same problem without disconnection.
=# checkpoint;
=# select pg_switch_xlog();
This is somewhat artifical but the same situation could be made
also in the nature. The exact condition for this is replaying a
checkpoint record having no buffer modification since the
preceding checkpoint in the previous WAL segments.
Returning to the discussion on which way to choose, we agreed
that using replayEndRecPtr instead of minRecoveryPoint in
do_pg_stop_backup(), as the patch attached to the following
message.
https://www.postgresql.org/message-id/CAB7nPqTv5gmKQcNDoFGTGqoqXz2xLz4RRw247oqOJzZTVy6-7Q@mail.gmail.com
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center