Fujii Masao wrote: > On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers <e...@xs4all.nl> wrote: >> With this patch the standby compiles, tests, installs OK. >> I wanted to check with you if the following is expected. > > Thanks for the test and bug report! > >> With standby (correctly) as follows : >> LOG: redo starts at 0/1000020 >> LOG: consistent recovery state reached at 0/2000000 >> LOG: database system is ready to accept read only connections >> >> This is OK. >> >> However, initially (even after the above 'ready' message) >> the timeline value as reported by >> pg_xlogfile_name_offset(pg_last_xlog_replay_location()) >> is zero. > > When we try to read the WAL record discontinuously (e.g., the REDO > starting record and the last applied record), the lastPageTLI is > always reset. If that record is not in the buffer, it's read from > the disk and the lastPageTLI is set to the right timeline. Otherwise, > the lastPageTLI remains at zero wrongly. This is the cause of the > problem that you reported. > > I revised the patch so that the lastPageTLI is always set correctly. > Please try this new patch.
This still suffers from ambiguity around a shutdown checkpoint that changes the TLI. On the page the shutdown checkpoint is on, what is the TLI in the page header? The TLI before the checkpoint record, I presume. Now consider a record on the same page after the checkpoint record. It's on the new timeline, but pg_last_xlog_replay_location() will return the old TLI, because that's on the page header. It's not clear what it should return, a TLI corresponding the filename of the WAL segment the record was replayed from, so that you can use pg_xlogfile_name() to find out the filename of the WAL segment being replayed, or the accurate TLI of the record being replayed. I'm leaning towards the latter, it feels more correct and accurate, but you could argue for the former too. In any case, it needs to be well-defined. -- 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