On Mon, Jul 11, 2016 at 3:31 PM, Magnus Hagander <mag...@hagander.net> wrote: > > > On Thu, Jul 7, 2016 at 8:38 AM, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> >> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini >> <marco.nenciar...@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. >> >> 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. > > > I agree this looks correct. > > But isn't this also a pre-existing bug in 9.5? Or did we change something > else that suddenly made it visible? >
I think the bug is pre-existing, but it becomes visible to user now by new API. -- 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
