Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby - Mailing list pgsql-hackers

<p dir="ltr"><br /> On Jul 9, 2016 4:52 AM, "Noah Misch" <<a
href="mailto:noah@leadboat.com">noah@leadboat.com</a>>wrote:<br /> ><br /> > On Thu, Jul 07, 2016 at
03:38:26PM+0900, Michael Paquier wrote:<br /> > > On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini<br /> >
><<a href="mailto:marco.nenciarini@2ndquadrant.it">marco.nenciarini@2ndquadrant.it</a>> wrote:<br /> > >
>After further analysis, the issue is that we retrieve the starttli from<br /> > > > the ControlFile
structure,but it was using ThisTimeLineID when writing<br /> > > > the backup label.<br /> > > ><br
/>> > > I've attached a very simple patch that fixes it.<br /> > ><br /> > > ThisTimeLineID is
alwaysset at 0 on purpose on a standby, so we<br /> > > cannot rely on it (well it is set temporarily when
recyclingold<br /> > > segments). At recovery when parsing the backup_label file there is no<br /> > >
actualuse of the start segment name, so that's only a cosmetic<br /> > > change. But surely it would be better to
getthat fixed, because<br /> > > that's useful for debugging.<br /> > ><br /> > > While looking at
yourpatch, I thought that it would have been<br /> > > tempting to use GetXLogReplayRecPtr() to get the timeline
IDwhen in<br /> > > recovery, but what we really want to know here is the timeline of the<br /> > > last
REDOpointer, which is starttli, and that's more consistent with<br /> > > the fact that we use startpoint when
writingthe backup_label file. In<br /> > > short, +1 for this fix.<br /> > ><br /> > > I am adding
thatin the list of open items, adding Magnus in CC whose<br /> > > commit for non-exclusive backups is at the
originof this defect.<br /> ><br /> > [Action required within 72 hours.  This is a generic notification.]<br />
><br/> > The above-described topic is currently a PostgreSQL 9.6 open item.  Magnus,<br /> > since you
committedthe patch believed to have created it, you own this open<br /> > item.  If some other commit is more
relevantor if this does not belong as a<br /> > 9.6 open item, please let us know.  Otherwise, please observe the
policyon<br /> > open item ownership[1] and send a status update within 72 hours of this<br /> > message. 
Includea date for your subsequent status update.  Testers may<br /> > discover new open items at any time, and I
wantto plan to get them all fixed<br /> > well in advance of shipping 9.6rc1.  Consequently, I will appreciate
your<br/> > efforts toward speedy resolution.  Thanks.<br /> ><br /> > [1] <a
href="http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com">http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com</a><br
/><pdir="ltr">I'll take a look at this on Monday when I'm back home from Russia. It looks like people have it under
control,so hopefully that just means committing the available solution in which case it'll be finished by then. <p
dir="ltr">/Magnus<br />