On Wed, Jul 20, 2016 at 5:12 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> 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:
>> 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,
>

Yeah, I think that is totally different angle to fix this issue, so
don't you think it is better to start a separate thread to discuss
about it for 10.0 and mark this patch as ready for committer.

>
>>> 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.
>

Okay, may be we can add a comment in code to indicate the same, but
OTOH, it is apparent from code, so not sure if it is worth to add it.


-- 
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

Reply via email to