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.
Hmm, currently pg_last_xlog_receive_location() returns the last locationstreamed via streaming replication. Should that
bechanged 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
