On Thu, Apr 8, 2010 at 4:06 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
pg_last_xlog_receive_location() might be executed also after archive recovery ends. In this case, using the current tli seems not correct because it's always different from the recovery target tli after recovery. >> 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. Should it advance when WAL file in pg_xlog is read? If not, pg_last_xlog_receive_location() can be smaller than pg_last_xlog_replay_location(). And, how far should it advance when WAL file is partially-filled for some reasons? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
