On Thu, Jul 7, 2016 at 12:08 PM, 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. >
+1, the fix looks right to me as well. -- 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
