From: Heikki Linnakangas on
Fujii Masao wrote:
> On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
> <heikki.linnakangas(a)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(a)mail.gmail.com
>> and
>> http://archives.postgresql.org/message-id/3f0b79eb1003300214r6cf98c46tc9be5d563ccf48db(a)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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers