Hello,
At Thu, 07 Jul 2016 17:26:15 +0900, Kyotaro HORIGUCHI
<horiguchi.kyot...@lab.ntt.co.jp> wrote in
<20160707.172615.232806225.horiguchi.kyot...@lab.ntt.co.jp>
> > 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.
The following sentense will be added by this patch. Does it make sense?
| Note that these two functions use the timeline ID at the time
| to construct the file name. Therefore they give wrong names for
| transaction log locations on the other timelines. This can
| happen during runtime on replication standby when a promotion
| occurs on itself or upstreams.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index baef80d..451f0ec 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17796,7 +17796,11 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
these functions return the name of the preceding transaction log file.
This is usually the desired behavior for managing transaction log archiving
behavior, since the preceding file is the last one that currently
- needs to be archived.
+ needs to be archived. Note that these two functions use the timeline ID at
+ the time to construct the file name. Therefore they give wrong names for
+ transaction log locations on the other timelines. This can happen during
+ runtime on replication standby when a promotion occurs on itself or
+ upstreams.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
