(moving to pgsql-hackers) Simon Riggs wrote: > On Wed, 2010-04-07 at 06:12 +0000, Heikki Linnakangas wrote: >> Log Message: >> ----------- >> Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset() during >> recovery. We might want to relax this in the future, but ThisTimeLineID >> isn't currently correct in backends during recovery, so the filename >> returned was wrong. > > Any reason why we couldn't just do this: > > if (RecoveryInProgress()) > { > volatile XLogCtlData *xlogctl = XLogCtl; > XLogFileName(xlogfilename, xlogctl->ThisTimeLineID, > xlogid, xlogseg); > } > else > XLogFileName(xlogfilename, ThisTimeLineID, xlogid, xlogseg); > > > rather than preventing access to those functions completely?
Because if you do something like pg_xlogfile_name(pg_last_xlog_receive_location()), xloctl->ThisTimeLineId would not necessarily be the timeline corresponding the last received location. Even with pg_xlogfile_name(pg_last_xlog_replay_location()), there's a small race condition between those calls; if a checkpoint record is replayed in between that changes timeline, the returned filename doesn't correspond the name of the file where the replayed WAL record was read from, as you would expect. 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. -- 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