Re: Streaming replication and pg_xlogfile_name()

Fujii Masao wrote:
> In relation to the functions added recently, I found an annoying problem;
> pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
> wrong name because pg_xlogfile_name() always uses the current timeline,
> and a backend doesn't know the actual timeline related to the location
> which pg_last_xlog_receive/replay_location() reports. Even if a backend
> knows that, pg_xlogfile_name() would be unable to determine which timeline
> should be used.

Hmm, I'm not sure what the use case for this is, but I agree it seems
annoying that you can almost reconstruct the exact filename, but not
quite because of the possible change in timeline ID.

> To solve this problem, I'm thiking to add the following functions:
> 
> * pg_current_timeline() reports the current timeline ID.
> * pg_last_receive_timeline() reports the timeline ID which is related
>    to the last WAL receive location.
> * pg_last_replay_timeline() reports the timeline ID which is related
>    to the last WAL replay location.
> * pg_xlogfile_name(location text [, timeline bigint ]) reports the WAL
>    file name using the given timeline. By default, the current timeline
>    is used.
> * pg_xlogfile_name_offset(location text [, timeline bigint]) reports
>    the WAL file name and offset using the given timeline. By default,
>    the current timeline is used.

That gets quite complicated to use. And there's a little race condition
too: when you call pg_last_replay_timeline() and
pg_last_xlog_replay_location() functions to get the timeline and
XLogRecPtr of the last replayed record, the timeline might change in
between the calls, so you end up with a combination that was never
actually replayed.

How about extending the format of the string returned by
pg_last_xlog_receive/replay_location() to include the timeline ID? When
it currently returns e.g '6/200016C', it could return '1/6/200016C',
where 1 is the timeline ID. Then just teach pg_xlogfile_name[_offset]()
to accept that format as well.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com