On Tue, Jul 19, 2016 at 10:43 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sat, Jul 16, 2016 at 9:20 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Wed, Jul 13, 2016 at 8:56 AM, Michael Paquier >> <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
