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.linnakan...@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/3f0b79eb1003030603ibd0cbadjebb09fa424930...@mail.gmail.com > >> and > >> http://archives.postgresql.org/message-id/3f0b79eb1003300214r6cf98c46tc9be5d563ccf4...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
