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

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: BUG #14230: Wrong timeline returned by pg_stop_backup on a standby
Date: 2016-07-07 06:38:26
Message-ID: CAB7nPqT9v45=+Nixv=pcnOOWUQ2tE8TX77-TcKEZ56tvyt4s2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
<marco(dot)nenciarini(at)2ndquadrant(dot)it> wrote:
> After further analysis, the issue is that we retrieve the starttli from
> the ControlFile structure, but it was using ThisTimeLineID when writing
> the backup label.
>
> I've attached a very simple patch that fixes it.

ThisTimeLineID is always set at 0 on purpose on a standby, so we
cannot rely on it (well it is set temporarily when recycling old
segments). At recovery when parsing the backup_label file there is no
actual use of the start segment name, so that's only a cosmetic
change. But surely it would be better to get that fixed, because
that's useful for debugging.

While looking at your patch, I thought that it would have been
tempting to use GetXLogReplayRecPtr() to get the timeline ID when in
recovery, but what we really want to know here is the timeline of the
last REDO pointer, which is starttli, and that's more consistent with
the fact that we use startpoint when writing the backup_label file. In
short, +1 for this fix.

I am adding that in the list of open items, adding Magnus in CC whose
commit for non-exclusive backups is at the origin of this defect.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Prashanth Adiyodi 2016-07-07 14:06:29 Where clause in pg_dump: need help
Previous Message Peter Geoghegan 2016-07-07 02:15:51 Re: BUG #14150: Attempted to delete invisible tuple

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2016-07-07 06:59:30 Re: pg_xlogfile_name_offset() et al and recovery
Previous Message Amit Kapila 2016-07-07 05:41:15 Re: Documentation fixes for pg_visibility