Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()

On Thu, Apr 8, 2010 at 4:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)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(dot)linnakangas(at)enterprisedb(dot)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.
>
> 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