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. 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(). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
