Fujii Masao wrote: > On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: >> 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. > > Sounds good. The attached patch does so. Also the code is available > in the 'replication' branch in my git repository.
> --- 5866,5882 ---- > /* use volatile pointer to prevent code rearrangement */ > volatile XLogCtlData *xlogctl = XLogCtl; > > ! /* > ! * initialize shared replayEndRecPtr, > recoveryLastRecPtr and > ! * recoveryLastTLI. Actually, the latter two variables > don't need to > ! * be initialized here since they are expected to be > updated at least > ! * once until read only connections will have read > them. But just in > ! * case. > ! */ > SpinLockAcquire(&xlogctl->info_lck); > xlogctl->replayEndRecPtr = ReadRecPtr; > xlogctl->recoveryLastRecPtr = ReadRecPtr; > + xlogctl->recoveryLastTLI = curFileTLI; > SpinLockRelease(&xlogctl->info_lck); > > InRedo = true; Thinking about this again, I'm not sure this is a good idea. Using curFileTLI makes sense if you're going to call pg_xlogfile_name() and would expect it to return the filename of the file containing the WAL record being replayed. But in other contexts, it seems strange for pg_last_replay_timeline() to return the TLI of the first record in the file, rather than the actual record replayed. I don't have any better ideas, though. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
