On Tue, Jul 19, 2016 at 9:08 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 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?
Yes, I mentioned an idea upthread to set up the minimum recovery point saved in the backup to the last replayed LSN. Though that's not acceptable for 9.6 as this requires changing the output of pg_stop_backup() with a new field containing the bytes of pg_control. I am not sure how others feel about that, so for now and the back-branches we could just document that updating the field after taking a backup closes any holes, and prevents to open a hot standby for read-only connections too early. >> 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? When taking a backup from a standby, there is no XLOG_BACKUP_END that can be used to determine when a hot standby is open for read-only connections. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
