At Thu, 7 Jul 2016 16:48:57 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp>
wrote in <3649f1e4-ac74-841e-6ae5-cfe0022aa...@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...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
