Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby
От | Amit Kapila |
---|---|
Тема | Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby |
Дата | |
Msg-id | CAA4eK1+WLFzyOskYQau31PhpCd=Bf69bioawBpgANR7miD1eSw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: