Re: pg_xlogfile_name_offset() et al and recovery

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: pg_xlogfile_name_offset() et al and recovery
Дата
Msg-id 20160707.172052.213690356.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: pg_xlogfile_name_offset() et al and recovery  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: pg_xlogfile_name_offset() et al and recovery  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
At Thu, 7 Jul 2016 16:48:57 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in
<3649f1e4-ac74-841e-6ae5-cfe0022aa50b@lab.ntt.co.jp>
> On 2016/07/07 16:26, Michael Paquier wrote:
> > On Thu, Jul 7, 2016 at 3:59 PM, Amit Langote
> > <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> >> While reading the thread "BUG #14230: Wrong timeline returned by
> >> pg_stop_backup on a standby", I came to know that ThisTimelineId is
> >> invalid on standby.  And because pg_xlogfile_name_offset() uses the same
> >> to compute its result, it makes sense to prevent it from being used on a
> >> standby.
> > 
> > To be honest, I have always found that this restriction was hard to
> > justify on a function that basically performs a static calculation. So
> > what about removing this error and use GetXLogReplayRecPtr() to fetch
> > the timeline ID? Per se the patch attached:
> > =# select * from pg_xlogfile_name_offset(pg_last_xlog_replay_location());
> >         file_name         | file_offset
> > --------------------------+-------------
> >  000000010000000000000003 |        2192
> > (1 row)
> > 
> > The same applies of course to pg_xlogfile_name():
> > =# select pg_xlogfile_name(pg_last_xlog_replay_location());
> >      pg_xlogfile_name
> > --------------------------
> >  000000010000000000000003
> > (1 row)
> 
> +1 to enabling these functions' usage on standby and the patch.

Strongly agreed. At first I thought that using replay-loc TLI is
bogus but ThisTimeLineID for non-recovery time is also bogus at
almost the same degree.

> =# select * from pg_xlogfile_name_offset('0/100'::pg_lsn);
>         file_name         | file_offset 
> --------------------------+-------------
>  000000030000000000000000 |         256

The rest of the "almost" is master's timeline evolution. A master
won't get timeline evolution during runtime but a standby can do.

As the result, this relaxation adds more good than bad and I
agree to this.

Addition to that, I'd like to propose to add a description (or a
notice) about this restriction in documentation that the timeline
part of the file name may be wrong. Will post soon.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Header and comments describing routines in incorrect shape in visibilitymap.c
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: pg_xlogfile_name_offset() et al and recovery