On Thu, Jul 7, 2016 at 12:08 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> <marco.nenciarini@2ndquadrant.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.
>
+1, the fix looks right to me as well.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com