I wrote a bit wrong thing.
At Thu, 07 Jul 2016 17:20:52 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20160707.172052.213690356.horiguchi.kyotaro@lab.ntt.co.jp>
> > > 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
It makes non sense. should be the follwoing,
| The rest of the "almost" is the upstreams' timeline evolution
| and promotion of itself. 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