Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

From: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
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 12:22:35
Message-ID: 9e092c86-5a8a-4732-cd5f-07a79c47b5f3@2ndquadrant.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 08/07/16 13:10, Michael Paquier wrote:
> 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.
>

Yes, it is exactly the same bug. My proposal was based on the assumption
that it were only a cosmetic issue, but given that it can trigger
errors, I agree that the right solution is to advance the minimum
recovery point in that case.

Regards,
Marco

--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco(dot)nenciarini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2016-07-08 15:08:22 Re: BUG #14237: Terrible performance after accidentally running 'drop index' for index still being created
Previous Message Sameer Kumar 2016-07-08 12:13:01 Re: [BUGS] Where clause in pg_dump: need help

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-07-08 12:27:34 Re: Showing parallel status in \df+
Previous Message Michael Paquier 2016-07-08 12:14:41 Re: Header and comments describing routines in incorrect shape in visibilitymap.c