From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it> |
Cc: | francesco(dot)canovai(at)2ndquadrant(dot)it, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby |
Date: | 2016-07-08 11:10:38 |
Message-ID: | CAB7nPqTGtk=7ZC-XBjDEfbD5LRXTf8qdiQUJw9tbzpeKubhSzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Fri, Jul 8, 2016 at 6:40 PM, Marco Nenciarini
<marco(dot)nenciarini(at)2ndquadrant(dot)it> wrote:
> The resulting backup is working perfectly, because Postgres has no use
> for pg_stop_backup LSN, but this can confuse any tool that uses the stop
> LSN to figure out which WAL files are needed by the backup (in this case
> the only file needed is the one containing the start checkpoint).
>
> After some discussion with Álvaro, my proposal is to avoid that by
> returning the stoppoint as the maximum between the startpoint and the
> min_recovery_end_location, in case of backup from the standby.
You are facing a pattern similar to the problem reported already on
this thread by Horiguchi-san:
http://www.postgresql.org/message-id/20160609.215558.118976703.horiguchi.kyotaro@lab.ntt.co.jp
And it seems to me that you are jumping to an incorrect conclusion,
what we'd want to do is to update a bit more aggressively the minimum
recovery point in cases on a node in recovery in the case where no
buffers are flushed by other backends.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Scott | 2016-07-08 11:47:43 | Problem with FSM & streaming replication |
Previous Message | dwaller | 2016-07-08 10:24:07 | BUG #14237: Terrible performance after accidentally running 'drop index' for index still being created |
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-07-08 11:37:23 | Re: A Modest Upgrade Proposal |
Previous Message | Craig Ringer | 2016-07-08 10:58:17 | Re: A Modest Upgrade Proposal |