On Tue, Jul 19, 2016 at 10:43 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Sat, Jul 16, 2016 at 9:20 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, Jul 13, 2016 at 8:56 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> Another way that just popped into my mind is to add dedicated fields
>>> to XLogCtl that set the stop LSN of a backup the way it should be
>>> instead of using minRecoveryPoint. In short we'd update those fields
>>> in CreateRestartPoint and UpdateMinRecoveryPoint under
>>> XLogCtl->info_lck. The good thing is that this lock is already taken
>>> there. See patch (2) accomplishing that.
>>
>> How is it different/preferable then directly using
>> XLogCtl->replayEndRecPtr and XLogCtl->replayEndTLI for stop backup
>> purpose? Do you see any problem if we go with what Kyotaro-san has
>> proposed in the initial patch [1] (aka using
>> XLogCtl->lastReplayedEndRecPtr and XLogCtl->lastReplayedTLI as stop
>> backup location)?
>
> Re-reading this thread from scratch and scratching my mind, I am
> actually not getting why we bumped into the topic of making
> minRecoveryPoint updates more aggressive instead of the first proposal
> :)
>
> Knowing that we have no way to be sure if pg_control has been backed
> up last or not, using the last replay LSN and TLI would be the most
> simple solution, so let's do this for back-branches.
>
Why only for back-branches? Do you have better solution for head?
> It is an
> annoyance to not be able to ensure that backups are taken while the
> master is stopped or if there is no activity that updates relation
> pages.
>
> The thing that is really annoying btw is that there will be always a
> gap between minRecoveryPoint and the actual moment where a backup
> finishes because there is no way to rely on the XLOG_BACKUP_END
> record.
>
Sorry, but I am not able to understand what you mean by above. What
kind of relation you are trying to show between minRecoveryPoint and
backup finish point?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com