On Thu, 2010-04-08 at 09:54 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
> > <heikki.linnakangas@enterprisedb.com> wrote:
> >> This commit is a stop-gap solution until we figure out what exactly to
> >> do about that. Masao-san wrote a patch that included the TLI in the
> >> string returned by pg_last_xlog_receive/replay_location() (see
> >> http://archives.postgresql.org/message-id/3f0b79eb1003030603ibd0cbadjebb09fa4249304ba@mail.gmail.com
> >> and
> >> http://archives.postgresql.org/message-id/3f0b79eb1003300214r6cf98c46tc9be5d563ccf48db@mail.gmail.com),
> >> but it still wasn't clear it did the right thing in corner-cases where
> >> the TLI changes. Using GetRecoveryTargetTLI() for the tli returned by
> >> pg_last_receive_location() seems bogus, at least.
> >
> > Why? The tli of the last WAL record received is always the
> > recovery target tli currently.
>
> True.
Only in streaming mode. If you use the current TLI as I have suggested
then it will be correct in more cases.
> Hmm, currently pg_last_xlog_receive_location() returns the last location
> streamed via streaming replication. Should that be changed so that it
> also advances when a WAL segment is restored from archive? It seems
> strange that pg_last_xlog_receive_location() can be smaller than
> pg_last_xlog_replay_location().
Yes, it should be changed.
-- Simon Riggs www.2ndQuadrant.com
